AKBridge MCP Server
Server Quality Checklist
Latest release: v0.1.2
- Disambiguation2/5
Many tools have overlapping purposes, such as multiple real-time A-share quotes (stock_zh_a_spot, stock_zh_a_spot_em, stock_zh_a_spot_tx) and several historical price functions (stock_zh_a_daily, stock_zh_a_hist). Duplicate macro indicators from different sources (e.g., macro_china_money_supply vs macro_china_supply_of_money) further blur boundaries, making it hard for agents to select the correct tool.
Naming Consistency4/5The majority of tools follow a clear snake_case pattern with domain prefixes and source suffixes (e.g., stock_zh_a_hist_em, fund_etf_spot_em). Some inconsistencies exist (get_*, match_main_contract, pro_api) but overall the naming is systematic and readable.
Tool Count1/5With 1093 tools, the server is massively over-scoped. This far exceeds any practical MCP server size, overwhelming context windows and making tool discovery and selection impractical. It is a raw dump of a large Python library rather than a curated toolset.
Completeness5/5The tool set covers an enormous range of financial data: equities (A-share, HK, US), funds, futures, options, bonds, foreign exchange, cryptocurrencies, macro indicators for multiple countries, indices, and more. It also includes non-financial utilities (NLP, sunrise), showing very broad coverage for a data retrieval service.
Average 3.3/5 across 926 of 1093 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint: true and readOnlyHint: false, so the agent knows it is a write operation. However, the description adds no context about side effects, whether it overwrites existing tokens, or any permission requirements. With annotations present, some baseline is given, but the description itself contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but conciseness requires every sentence to add value. Here, it only repeats the tool name, making it under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a destructive action and a single opaque parameter, the description provides no operational context. It does not explain how the token will be used, what happens on success, or how to recover from mistakes, making it far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'token' parameter, and the description does not explain what type of token is expected, where it comes from, or any formatting requirements. The description fails to compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'AKShare API: set_token' merely restates the tool name with a library prefix. It does not state what setting a token does or distinguish this from siblings like get_token or pro_api, providing no actual purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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, when not to, or what prerequisites (e.g., obtaining a token) are required. The description offers no context for selecting this tool over 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. However, the description adds no behavioral context beyond this—no mention of data source, return characteristics, symbol format, or any operational nuances. The description contributes zero additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, this is under-specification rather than concise effective communication. A single sentence that merely restates the tool name does not earn its place; it provides no informative content. The structure is minimal but functionally empty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data-fetching tool with one parameter and no output schema, the description is critically incomplete. It does not explain what data is returned, what 'individual pledge ratio' means, or how it differs from closely related tools. The combination of a zero-information description and minimal schema leaves the agent unable to use this tool correctly or predict its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'symbol' has no description in the schema (0% coverage) and the description provides no meaning, format, or example. The agent cannot infer what a valid symbol looks like (e.g., '600000' vs 'sh600000') or how it relates to the pledge ratio domain. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is purely tautological: "AKShare API: stock_gpzy_individual_pledge_ratio_detail_em" simply restates the tool name with a prefix. It does not state what the tool does, what resource it operates on, or what 'individual pledge ratio detail' means. It fails to convey any specific verb, action, or domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its many siblings, such as stock_gpzy_pledge_ratio_detail_em or stock_gpzy_industry_data_em. There is no mention of use cases, exclusions, or selection criteria. The description is just a label with no contextual direction.
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?
Annotations declare readOnlyHint true, destructiveHint false, and idempotentHint true, but the description adds no behavioral context beyond that. It does not mention data source behavior, rate limits, side effects, or any operational traits, despite the URL hinting at a data center endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It contains only a URL and a return-type line, which do not earn their place as a meaningful description. The brevity is not purposeful conciseness but a lack of substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the cryptic name and lack of output schema, the description is completely inadequate. It fails to explain what the tool does, what data it retrieves, or what 'specific time representation' means, leaving the agent unable to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter semantics since there are none to document; the empty schema already fully covers this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides only a URL and a return type ('dictionary representing a specific time'), with no verb or resource indicating what the tool actually does. The name 'stock_js_weibo_nlp_time' is cryptic, and the description does not clarify its function or distinguish it from any of the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 contains no context about scenarios, prerequisites, or exclusions, leaving the agent completely without direction for 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?
Annotations declare readOnlyHint=true and destructiveHint=false, so the tool's safety profile is partially known. However, the description adds almost no behavioral detail beyond these annotations, stating only "提问" (question) as the return type without describing data scope, format, or edge cases. The hard-coded URL is not informative and may confuse the agent about expected inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but disjointed, mixing a title, a sample URL, and a docstring without a coherent narrative. The URL is unnecessary and consumes space without conveying actionable guidance. A single, well-structured paragraph would be far more effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description should clearly explain the return value and usage context. It only says ":return: 提问" (question), which is vague, and omits details about the data source, freshness, or limitations. The description is inadequate even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a docstring for the `symbol` parameter, defining it as a stock code (股票代码), which adds meaning beyond the bare schema. However, it does not specify the expected format, exchange, or constraints, and the default value "002594" implies but does not explicitly state that it expects Chinese A-share codes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description consists only of the title "互动易-提问" and a docstring snippet, with no explicit statement of what the tool does. It fails to use a clear verb+resource structure and does not distinguish itself from similar tools like stock_irm_ans_cninfo. The example URL referencing a specific question detail page further obscures the tool's intended function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 or how it relates to alternative tools. No prerequisites, exclusions, or comparison with sibling tools are mentioned, leaving the agent without any selection criteria.
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 already indicate readOnlyHint=false and destructiveHint=true, but the description adds no context about what side effects occur when getting a token. It doesn't clarify whether a token is created, refreshed, or invalidated, leaving behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
At six words, the description is minimal but vacuous; it provides no substantive information beyond the name, so its brevity is not a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that likely interacts with authentication state, the description lacks any explanation of return value, side effects, or relationship to set_token. Despite no parameters and no output schema, the tool is not self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so there is nothing to document. The baseline of 4 applies because no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Description reads 'AKShare API: get_token' — tautologically restates the tool name without specifying what 'token' means or what the tool returns. Sibling tools like set_token indicate it's about token management, but no resource/verb is clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call get_token versus set_token or other authentication-related tools. There is no context about prerequisites 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only profile. However, the description adds no behavioral context beyond the annotations—no mention of return format, data source behavior, or any operational constraints. It neither contradicts annotations nor enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It simply repeats the tool name and source, providing no usable information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a large family of similar AKShare option/futures tools, this description is severely incomplete. An agent cannot determine what data option_comm_symbol returns, how it differs from siblings, or how to invoke it meaningfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is nothing for the description to explain. The baseline score of 4 applies because parameter semantics are irrelevant when no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'AKShare API: option_comm_symbol' is a tautology—it restates the tool name with a source prefix but gives no verb or resource indicating what the tool does. There is no mention of listing symbols, retrieving data, or any functional purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 the numerous sibling tools such as option_comm_info, option_commodity_contract_sina, or option_sse_codes_sina. The description offers no context, prerequisites, 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. However, the description adds no behavioral context beyond this, leaving the actual return behavior and operational characteristics completely unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a brief label, which is under-specification rather than effective conciseness. It fails to earn its place because it conveys no actionable meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data-fetching tool with no output schema, the description must explain what data is returned and how to interpret it. Here, even the core purpose is missing, making the description completely inadequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object. With 0 params, the baseline is 4, and there is no param semantics needed. The description adds no param info, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely the tool name prefixed with 'AKShare API:', providing no statement of what the tool does. It is a tautology that restates the identifier without any verb or explanation of functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools. No scenarios, prerequisites, 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?
Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. However, the description adds no extra behavioral context such as data source reliability, update frequency, or access restrictions; it merely repeats source branding and return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but is under-specified rather than concise. It contains a brand name, a URL, and two cryptic docstring-like lines, none of which effectively communicate the tool's purpose or usage. Every line is present but lacks informative value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without parameters, output schema, or meaningful description, this tool is severely under-documented. The agent cannot determine what data is returned, what a 'specific time' means, or how the dictionary/DataFrame is structured, making this completely inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage is 100% with an empty properties object). The baseline is 4, and the description includes return type mentions (dictionary/DataFrame), which adds minimal semantic clarity even though it does not explain the structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a website name and URL (财新网-财新数据通) along with return type hints, but never states what the tool actually does. There is no verb or resource indicating the function; the tool name suggests 'stock news' but the description fails to confirm or explain it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. The description lacks any context about use cases, prerequisites, or exclusions, leaving the agent without direction among the many sibling data 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds only a source URL and return type (pandas DataFrame), but does not disclose behavior such as date format requirements, pagination, or network dependence. It provides minimal extra context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not excessively verbose, but its structure is a docstring-like mix of title, URL, and param/return annotations. The first line merely restates the title from annotations, and the content is not front-loaded with a clear purpose sentence. It is compact but somewhat disorganized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is still incomplete. It does not specify the date format, what columns will be returned, or which exchange (beyond the name). With no output schema, more detail on the return structure and usage context is needed. The URL provides a source but no functional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with no description (0% schema coverage), so the description carries the burden. It gives a Chinese label '期转现日期' (futures-to-spot date) and type 'str', but does not clarify the expected format. The default '202312' hints at YYYYMM, but ambiguity remains (full date vs. month). This adds only thin meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a Chinese translation of the tool name (大连商品交易所-期转现 = DCE futures-to-spot) plus a URL. It lacks a clear verb phrase like 'Get futures-to-spot quotation data for DCE'. It identifies the exchange and data type but does not state what action is performed or what output is provided, making it only marginally more informative than the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. Sibling tools include futures_to_spot_czce and futures_to_spot_shfe, but the description does not mention that this is specific to DCE or point to alternatives for other exchanges. No exclusions, prerequisites, or context for selection 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. However, the description adds no behavioral context beyond the return type (pandas.DataFrame). It does not disclose what the data contains, whether it is historical or real-time, or any quirks. The URL is unexplained. With annotations present, the description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repetitive, repeating '玄田数据-成本维度' three times (in the title, the source line, and the return doc). The docstring structure is standard, but the URL is unexplained and the repeated content does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, the description is severely incomplete. It does not explain what the cost dimension data contains, how it relates to hog futures, or what makes it distinct from sibling tools. There is no output schema, so the description should explain return content but only gives a generic return type. This is insufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists the allowed values for the `symbol` parameter: {"玉米", "豆粕", "二元母猪价格", "仔猪价格"}. This is crucial because the input schema does not include an enum or description. With schema description coverage at 0%, the description compensates well for parameter semantics, though it could further explain what each symbol represents in the context of 'cost'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a Chinese title '玄田数据-成本维度' (Xuandian Data - Cost Dimension) without any verb or action. It does not state what the tool does, such as 'retrieves cost data for hog futures'. The resource is implied from the tool name, but the description restates the title in the return line, making it largely tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance on when to use this tool versus alternatives like futures_hog_core or futures_hog_supply. The description only provides a data source URL and parameter documentation but no context for selection, prerequisites, 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is fully covered. The description adds the source URL and the fact that it returns a pandas.DataFrame in the docstring, which is useful but minimal. It does not disclose behavioral details like date format handling, pagination, or row contents, so it provides only modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concisely informative; it is under-specified. It blends a title, URL, and docstring without forming a clear, complete sentence. A concise description would convey the tool's purpose and key behavior, but this one only provides a label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and rich annotations, so it is simple, but the description is still incomplete. It does not explain what the macro calendar contains, how the date parameter filters results, or when to prefer this tool over the many other macro_* siblings. The return type is given, but the returned data structure is not outlined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description's docstring for 'date' merely says '日期' (date), which only restates the parameter name. It does not specify the expected format (e.g., YYYYMMDD) beyond the schema default. The return type is mentioned but no return structure is described. Thus the description adds very little semantic value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a title and a URL: '华尔街见闻-日历-宏观' and 'https://wallstreetcn.com/calendar'. It lacks an explicit verb or statement of what the tool does beyond implying macro calendar data. There is no clear differentiation from the many sibling macro_* tools that also provide macro-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 the numerous similar macro tools. There is no mention of context, exclusions, or alternatives. The description is purely nominal and provides no decision support.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds no behavioral context beyond that—no mention of rate limits, response size, or any side effects. The only additional detail is the source URL, which is not behavioral. Given the low bar for annotated tools, this still scores low because the description adds essentially no transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but it is under-specified rather than concise. It repeats '板块简介' multiple times and lacks a clear, structured sentence explaining the tool's purpose. The URL and docstring format are not front-loaded with actionable information. It is shorter than it should be, but not in a way that earns conciseness credit—it omits essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what the returned DataFrame contains, but it only says '板块简介' (sector introduction) with no field details. The parameter semantics are also ambiguous, leaving an agent unable to construct a valid call confidently. Despite the simple one-parameter tool, the description is severely incomplete for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'symbol' is 0%, and the description's ':param symbol: 板块简介' is unhelpful and redundant—it says the parameter is the sector introduction, not what values it accepts (e.g., name vs. code). The default '阿里巴巴概念' suggests a name, but the URL contains a code, creating ambiguity. The description fails to clarify the parameter format, making it nearly useless for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a title '同花顺-板块-概念板块-板块简介' followed by a URL and docstring, indicating it returns a concept sector introduction. It identifies the resource (concept board) and return type (DataFrame), but lacks an explicit verb like 'get' or 'fetch'. It is somewhat distinguishable from sibling tools by the word '简介' (introduction), but not clearly differentiated from similar THS concept board 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/5Does 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 preferred use cases, exclusions, or relationships to other concept board tools such as stock_board_concept_spot_ths or stock_board_concept_summary_ths. The only context is a URL and parameter docstring, which do not help in 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds a source URL and return type, but no behavioral context such as data freshness, network requirements, or limitations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a long hierarchical label, then a URL, then a docstring. Important information is buried and not front-loaded. It could be rewritten as a clear sentence like 'Get bond details by bond symbol, returning a pandas DataFrame.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, but the description does not explain what fields are in the returned DataFrame or how to interpret the bond details. It also does not mention the relationship between symbol and the URL's bondDefinedCode, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents ':param symbol: 债券简称', clarifying that symbol means 'bond short name' beyond the raw schema. This is valuable since schema description coverage is 0%, and the default example gives a concrete format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a menu path ('数据-债券信息-信息查询-债券详情') rather than a clear verb+resource statement. It implies retrieving bond details but does not explicitly say 'get details for a given bond symbol' or distinguish from sibling tools like bond_info_cm or bond_info_cm_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. No mention of prerequisites, scenarios, or exclusions. The description is purely a source path and docstring with no 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds only the source URL and return type 'dict' but no behavioral details such as the mapping direction, data freshness, or any caveats. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than effectively concise. It consists of a title, a URL, and a return type annotation, with no explanatory sentence about what the tool actually returns or how it behaves.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple no-parameter interface, the description is still incomplete because it fails to specify the structure of the returned dict, exactly what codes are included, or how the mapping works. This is critical for an agent to know whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema description coverage is 100% and there is nothing to document. The description is not required to add parameter semantics; baseline 4 for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a title (东方财富-股票和市场代码) and a return type note, not a clear verb+resource statement. It does not explain that this tool maps index codes to IDs, using 'stock and market codes' instead, which is ambiguous and does not distinguish it from many sibling index/stock tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. With over 400 sibling tools, no context is given for when a mapping of codes is needed or what specific use case it serves.
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 already declare readOnlyHint=true, destructiveHint=false, so the safety profile is clear. However, the description adds only a return type and data range, and these are clouded by the contradictory country references. It does not clarify what the returned pandas.Series contains (e.g., actual interest rate values) or the source's intended scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fragmented and not front-loaded. It contains two long URLs that are unnecessary for tool selection, and the China/New Zealand mismatch introduces noise rather than clarity. The return type and rtype are repeated in an unstructured manner, making it difficult to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description provides a date range and return type, the contradictory semantics and lack of a clear description of the actual data content make it incomplete. The tool is simple (no parameters), but the description fails to communicate what the series represents, leaving an agent unable to correctly use or interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the input schema is complete by default. The description's mention of the date range and return type provides some context, but with zero parameters, there is little to explain. Baseline of 4 is appropriate given the vacuum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is self-contradictory: it states '中国央行决议报告' (China central bank decision report) but then returns '新西兰联储决议报告-今值(%)' (New Zealand Fed decision report). This directly conflicting information makes the tool's true purpose ambiguous and misleading, preventing an agent from knowing what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only gives a data range and return type, without any context on use cases, prerequisites, or exclusions. The presence of many similar sibling tools highlights the lack of differentiation.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds only a return type (pandas.DataFrame) and a source URL, but does not disclose what the DataFrame contains, the index composition, data frequency, or any limitations. This is minimal and does not meaningfully enrich the behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but also repetitive, repeating '大宗商品价格' three times. It includes a URL and docstring-style return annotations, but no structured explanation. This is under-specification rather than efficient conciseness, as the space is not used to add meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool with no output schema, the description must at least clarify what the returned data represents, its granularity, and how it relates to sibling indices. Here, it only gives a generic Chinese label and a URL. Missing critical details like the index code EMI00662535, historical vs. current values, column structure, and update frequency make the description inadequate for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details to explain. Per the baseline rule, score 4 is appropriate because there is nothing for the description to add about parameters; it cannot be faulted for missing param semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '大宗商品价格' is essentially a noun phrase that restates the tool name (commodity price index) without a verb indicating an action. It does not clarify what the tool does (e.g., fetch, return) nor distinguish it from sibling tools like macro_china_energy_index or macro_china_construction_price_index. The URL is the only unique identifier, but it is not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 or when to prefer alternative macro index tools. The description lacks any mention of typical use cases, prerequisites, or exclusions. An agent given this description would have no idea how to select it over 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?
The description adds a URL and a return type (pandas.DataFrame), but it does not describe what data is contained, whether it is historical or current, what the DataFrame columns are, or any other behavioral details. Annotations already declare the tool read-only and safe, so the description adds minimal context beyond what annotations provide. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is repetitive: the first line duplicates the tool's title, and the ':return:' line repeats the same phrase. This is under-specification rather than purposeful conciseness. The URL is the only non-redundant piece of information, so the structure wastes its brevity on redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with no parameters, the annotations cover safety, but the description does not explain the data contents or structure. The lack of an output schema means the agent has no idea what columns, time range, or granularity to expect from the returned DataFrame. The URL and return type alone are insufficient for a complete understanding of the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The input schema is trivially complete (100% coverage), and for 0 params the baseline is 4. The description adds no parameter-specific information, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool's title '东方财富-本外币存款' without any action verb like 'fetch' or 'retrieve.' The only additional information is a source URL and a return type, which do not clarify what the tool actually does. This is a tautological description that lacks a clear purpose statement and does not distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context about when to use this tool or how it differs from similarly named macro_* tools. There are no alternatives mentioned, no exclusions given, and no indication of the appropriate scenario for invoking this tool. An agent would have zero guidance on 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. However, the description adds only a source URL and return type, which are not behavioral traits. It does not mention any side effects, data sources beyond the URL, 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specifies. It reads as a docstring metadata block rather than a structured tool description, lacking any actionable verb or context. Conciseness is not valuable when it omits essential purpose and usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 what the returned DataFrame contains beyond just '贸易帐'. It does not mention columns, time range, or any unique characteristics. Given the tool's simplicity, the description is still insufficient for an agent to fully understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage), so there is nothing to explain. The baseline for 0 params is 4, and the description correctly does not attempt to describe non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a title and return type, restating the tool name and the data it returns ('贸易帐' - trade account). It does not use a verb to indicate an action, and the only additional context is the source URL. This is close to tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. With numerous sibling tools like macro_uk_trade and macro_australia_trade, the description provides no selection criteria 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns a pandas DataFrame and takes a contract code, but it doesn't disclose what 'basic information' includes, any side effects, authentication needs, or behavior on invalid input. The added value beyond annotations 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (a docstring) and front-loaded, but it repeats '期权基本信息表' in both the description and return lines, which is redundant. It is concise in length but lacks substantive content that would justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description is incomplete: it doesn't explain the contents of the return table, the expected symbol code format, or any source-specific behavior. The mismatch between the 'greeks' name and 'basic information' description leaves a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does state that symbol is a '合约代码' (contract code), providing basic meaning, but offers no format guidance, examples, or clarification of the default '10003045'. This is insufficient to fully understand the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says '期权基本信息表' (option basic information table), which is vague and doesn't mention 'greeks' despite the tool name indicating that. It lacks a specific verb like 'get' or 'retrieve' and doesn't distinguish this from other option_sse_* sibling tools like option_sse_daily_sina or option_sse_spot_price_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings, exclusions, or prerequisites. The description only presents the parameter and return type without any contextual use case.
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?
The description adds that the return type is pandas.DataFrame, which is useful behavioral information. However, the return description ('T+0 QDII-亚洲市场') is misleading and contradicts the title, and no other behavioral traits (e.g., cookie usage, data freshness) are disclosed. With annotations already covering read-only/idempotent hints, the misleading return line prevents a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured: it starts with a title, then a URL, then a mislabeled return line that appears to be a copy-paste error. The information is not presented in a logical order, and the erroneous return statement wastes space and creates confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter and no output schema, so the description carries a moderate burden. It fails to explain the cookie parameter, clarify the market focus, or reconcile the contradictory return line. The missing details on the cookie and correct return value make it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has an optional 'cookie' parameter with zero description coverage. The description does not mention the cookie parameter at all, nor any other parameter details, so the agent cannot understand how or why to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource clearly (集思录-T+0 QDII-欧美市场-欧美指数) and includes a source URL, indicating it fetches European/American QDII index data from Jisilu. However, it lacks an explicit verb like 'get' or 'retrieve', and the return line says 'T+0 QDII-亚洲市场' (Asian market), which contradicts the stated European/American focus and confuses the actual 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/5Does 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 (e.g., qdii_a_index_jsl or qdii_e_comm_jsl). There are no prerequisites, examples, or exclusions mentioned, leaving the agent without context for selecting this 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. However, the description adds only the source URL and return type (pandas.DataFrame), and does not disclose behavioral traits such as the scope of data, whether it covers all stocks, or any potential rate limits. It adds minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse—just a title, a URL, and return type—but this is under-specification, not concise clarity. It does not front-load a purpose, and the structure (label, link, return) is not an effective description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description must explain what the returned data actually contains. It merely says '千股千评数据' (thousand-stocks thousand-comments data) and that it returns a DataFrame, without naming columns, data coverage, or semantics. This is insufficient for an agent to understand what it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, indicating zero parameters. According to the rubric, 0 params sets a baseline of 4. The description correctly implies no parameters are needed by not mentioning any, so no further parameter-specific explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a label and a URL: '东方财富网-数据中心-特色数据-千股千评' followed by a source link and return type. It does not state a clear action (e.g., 'retrieve', 'fetch') or explain what the tool accomplishes beyond naming a data source. It also does not distinguish itself from sibling tools like stock_comment_detail_*.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many similar stock_comment_detail_* siblings, nor any mention of alternatives, prerequisites, or exclusions. The description is purely descriptive with zero 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?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool's safety profile is clear. However, the description adds no behavioral context beyond that—no mention of data source freshness, potential delays, scope of the returned data, or any caveats. The only addition is the URL and return type, which are more structural than behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but that is not conciseness; it is under-specification. It provides a title, a URL, and a return type with no coherent sentence structure or explanation. It lacks a clear purpose statement and reads more like metadata dump than a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what the returned pandas DataFrame contains (columns, data granularity, time range, etc.). The URL is not self-explanatory for an AI agent. For a tool that claims to return '财经早餐', the description leaves out essential details that would help an agent judge whether the output is relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description does not need to explain any parameter semantics because there are none. The empty schema and the fact that it takes no inputs are already clear from the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool's title ('东方财富-财经早餐') without a clear verb or action. It gives a URL and return type but does not explain what the '财经早餐' content actually is or what the function does. It fails to distinguish the tool from many other news-related sibling tools like news_cctv or stock_news_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 or how it differs from alternatives. The description provides no context about typical use cases, exclusions, or preferred scenarios. An agent would have no idea when to pick this over other financial news or stock information 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?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the bar is lower. The description adds a source URL and return type (pandas.DataFrame) but does not disclose any behavioral traits such as data coverage, pagination, or potential network dependency. It adds little beyond the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains a redundant first line that exactly matches the title. The structure is docstring-like with URL and param/return, but the repeated title wastes space. It is not as concise as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter and no output schema, the description should clarify what data is returned and how it differs from similar tools. It only says it returns a DataFrame of executive shareholding changes from THS, without describing columns, date ranges, or use cases. This is insufficient for a tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only states 'symbol: 股票代码' (stock code), which is already obvious from the parameter name. No format, examples, or default behavior details are given, so the parameter semantics are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is '同花顺-公司大事-高管持股变动', which is identical to the title and essentially restates the tool name. It provides no verb or explicit action, only a noun phrase describing a data category, and does not differentiate from sibling tools like stock_hold_management_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only contains a URL and parameter documentation, with no mention of preferred use cases, exclusions, or 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?
The description only restates the return type and provides a URL, adding no behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint). It does not disclose data scope, pagination, scraping behavior, or other traits, so the agent cannot anticipate 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: '收盘收益率曲线历史数据' appears in both the first line and the :return: field. The URL is useful, but the repeated phrases could be consolidated without loss of information, making it slightly inefficient rather than taut but concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for selecting this tool among many bond-related siblings. It does not explain the 'map' in the tool name, the bond type implied by the URL (bondType=CYCC000), or the data's scope. Despite having no parameters and annotations, the missing differentiation and source details leave the tool's purpose unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and schema coverage of 100%, the baseline is 4. The description adds no parameter information, but none is needed since the tool accepts no arguments. The semantics are fully determined by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: it repeats the title '收盘收益率曲线历史数据' twice and provides a URL, but does not state a specific action or resource beyond the title. It also fails to distinguish from the related sibling tool bond_china_close_return, making the purpose ambiguous, especially regarding what 'map' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 bond_china_close_return or bond_china_yield. The description lacks any context about use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the source URL and return type, with no details about data contents, columns, or expectations. This goes slightly beyond annotations but lacks substantive 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and has no padding, but it is mostly a hierarchical title followed by a URL and return type. It is not front-loaded with an action or purpose, and the repetitive title could be considered waste. It earns a middle score for brevity without efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description is the only source of context. It fails to explain what specific convertible bond data is returned, such as columns, time range, or whether it is a snapshot. Given the abundance of sibling bond tools, this is insufficient for an agent to confidently select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline for parameter semantics is 4. The description provides no parameter-specific details, which is appropriate since none exist. No further compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a title: 'Eastmoney Data Center - New Stock Data - Convertible Bond Data'. It states the resource and source but lacks a specific verb like 'get' or 'list'. The return type indicates it returns convertible bond data, but this doesn't clearly distinguish it from numerous sibling convertible bond tools such as bond_zh_cov_info or bond_cov_comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 alternative bond tools. No mention of use cases, exclusions, or alternatives. The description simply names the data source and return type, leaving the agent to guess when this is 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds little behavioral context beyond the source URL and the generic return type 'pandas.DataFrame'. It does not describe data freshness, pagination, or any limitations, leaving the agent under-informed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring pattern, with a title, URL, and param/return sections. It avoids unnecessary filler, but some content (like the raw URL) may not be essential for an AI agent. Overall, it is concise and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what the returned DataFrame contains. '交易参数汇总查询' is ambiguous and does not describe columns, contract identifiers, or data granularity. The date format is also unspecified. For a futures contract info tool, this is incomplete and could lead to incorrect use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'date' parameter. The description provides ':param date: 查询日期' and ':type date: str', which adds basic meaning ('query date') but lacks required format (e.g., YYYYMMDD), allowed ranges, or whether it is optional. The default '20240228' in the schema implies format, but the description itself does not clarify it sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: it provides a title '郑州商品交易所-交易数据-参考数据' and a return description '交易参数汇总查询' (trading parameter summary query), but no explicit action like 'retrieve' or 'query'. It does not clearly state what the tool does beyond the name itself, and it fails to distinguish from sibling tools like futures_contract_info_dce or futures_contract_info_cffex.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No mention of exchange-specific use cases, prerequisites, or exclusions. The description only includes a URL and docstring param/return info, which does not help an agent decide when to invoke it.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds only that the return is a list of contract names. It does not disclose any additional behavioral traits such as date format handling, error cases, or dependencies. It does not contradict annotations but adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes only essential elements: title, source URL, parameter, and return. It is not verbose and is reasonably front-loaded, though the documentation-style fragments lack a unified, sentence-like structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple one-parameter signature and a return type, but the overall purpose is unclear due to the 'supplement' label. No output schema exists, and the description does not explain how this tool fits with related ranking tools or what 'other' distinguishes. The return type is provided, but usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description states the date parameter is a trading day (交易日), which adds some semantic meaning beyond the schema's type and default. However, it does not specify the expected format (e.g., YYYYMMDD) beyond the default value, and with only one parameter, the added meaning is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description mostly consists of the title, a URL, and parameter/return docs. It does not clearly state in a verb-driven sentence what the tool does. The title says 'supplement' but the function remains ambiguous, even though the return type indicates it yields a list of contract names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 does not mention its relationship to futures_dce_position_rank or any other tool, nor any prerequisites or conditions. The description is entirely silent on 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?
The description only adds that it returns a pandas.DataFrame; this is a minimal behavioral detail. It doesn't explain data source specifics, whether data is historical/realtime, or any side effects. The annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds little beyond that. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a structured return type, but most content is redundant with the title and name. The URL is the only unique piece of information. While it's not bloated, the redundancy means it doesn't earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large family of similar QVIX tools, the description fails to explain what 'min' indicates (likely minute-level data) or how this differs from index_option_50etf_qvix. It also doesn't specify the data range or update frequency. The provided URL is unexplained and may be a data source but lacks context. This leaves the tool insufficiently distinguished for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description correctly implies there are no inputs to worry about. Since there are no parameters, the baseline is 4, and the description doesn't need to provide parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name in Chinese ('50 ETF 期权波动率指数 QVIX') and provides a URL and return type. It does not explicitly state an action like 'fetch' or 'query,' and the purpose is largely inferred from the name. This is a tautology rather than a clear functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 sibling tools such as index_option_50etf_qvix (without 'min') or other index_option_*_qvix variants. The description doesn't mention use cases, prerequisites, or alternatives, leaving the agent without any context for 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat those. However, the description adds minimal context: a source URL and return type. It fails to disclose anything about the data content, periodicity, or potential quirks. The description is too sparse to be genuinely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and not verbose, which is positive. However, it is under-specified to the point of being a stub. It front-loads the title and a URL, but the content is too thin to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the returned DataFrame contains. It only says 'energy index' without specifying columns, time range, or meaning. The URL is a hint but not an explanation. The overall context is insufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description does not need to explain parameters, and it already specifies the return type as pandas.DataFrame, offering slight value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: '能源指数' (energy index) matches the tool name and provides no verb or action. It gives a source URL and return type, but does not clearly state what the tool does with the data, such as retrieving or listing energy index data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 compared to alternatives. It does not mention any similar tools, prerequisites, or specific scenarios. The lack of any usage context leaves the agent without direction.
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 already declare readOnlyHint=true and idempotentHint=true, lowering the bar for behavioral disclosure. The description adds only a return type (DataFrame) and a cookie parameter, but does not explain cookie requirements, potential data coverage, rate limits, or pagination. It adds minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and avoids extraneous text, but it is structured as a docstring fragment with a URL and parameter lines, not a coherent paragraph. It could be more readable with a clear imperative statement and logical ordering, though it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and only sparse annotations, the description is insufficient for an agent to understand the full behavior. It does not explain the date range semantics, whether historical data is available, how the cookie should be obtained, or what specific fields appear in the returned DataFrame. The tool likely serves a straightforward calendar query but the description leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It specifies the date parameter format (YYYYMMDD), which is useful, but the cookie parameter is merely repeated as 'cookie' without any explanation of purpose or acquisition. The return type is mentioned but no parameter behavior is clarified beyond the basic format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Baidu Stock Market financial report release calendar) and indicates it returns a DataFrame of financial report releases. However, it lacks an explicit action verb (e.g., 'fetch', 'query'), and the tool name 'news_report_time_baidu' is misleading compared to the actual subject matter. It is a clear label but not a full statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There is no mention of prerequisites, filters, or exclusions. The description simply lists a URL and parameters without any contextual advice on selecting this tool over the many sibling financial data 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds little behavioral context: it only states that the return is 'indicator data' without explaining what that means, how results are structured, or any constraints. No additional traits like rate limits or authentication needs are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but not effectively structured. It repeats the Chinese title, includes a URL that is unlikely to help an AI agent understand usage, and the param/return documentation is terse. It does not front-load a clear functional explanation, and the content is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 still feels incomplete. It fails to explain what the tool does in practical terms, what 'indicator data' consists of, or how it relates to the sibling 'nlp_ownthink'. An agent would struggle to know when to call this tool and what to expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'question' with type string and a default, but no property description. The description adds that the question should be a 'word in chinese', which provides useful language guidance beyond the schema. However, it does not clarify whether a full sentence is acceptable, and the term 'word' is potentially restrictive. The return type is mentioned but not tied to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '智能问答' (Intelligent Q&A), which is simply the tool's title restated, and provides a URL to ownthink.com. It does not state a specific verb+resource action, such as 'answer a question using the OwnThink robot'. The return type 'indicator data' is vague and does little to clarify what the tool actually does, and it fails to distinguish itself from the sibling tool 'nlp_ownthink'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like nlp_ownthink. The description only provides parameter documentation and a return type, with no mention of appropriate use cases, prerequisites, or exclusions. It is not misleading, but it provides no usage direction.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), but does not disclose any behavioral details such as data freshness, pagination, or latency. It provides minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and contains no fluff, but it is under-specified rather than efficiently concise. It repeats the title instead of providing meaningful structure or front-loaded actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain what '大单追踪' (big deal tracking) actually contains, what fields are in the DataFrame, or how this tool differs from similar fund flow tools. With no output schema and minimal description, an agent would not know the data's structure or use case, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage (vacuously). The baseline for zero parameters is 4, and the description does not need to explain parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a repetition of the title '同花顺-数据中心-资金流向-大单追踪' with a URL and return type. It lacks an explicit verb (e.g., 'fetch', 'list') and merely names the resource, making it a tautology rather than a clear statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. With numerous sibling tools covering different fund flow aspects (e.g., individual, industry, concept), the description offers no context for selection, exclusions, or prerequisites.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds only that it returns a pandas.DataFrame, which is useful but minimal. No additional behavioral context like pagination, data scope, or authentication needs is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, bordering on under-specification. It consists of a title-like path, a URL, and a return type label, with no complete sentence. While there is no fluff, the lack of structure or explanatory prose hurts clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the full responsibility of explaining what data is returned. It only says '可转债转股' (convertible bond stock conversion) and 'pandas.DataFrame', without describing columns, data granularity, or any other contextual details. This is insufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description bears no burden in explaining parameter behavior. The baseline of 4 applies because with no parameters, no semantic gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a navigation path ('巨潮资讯-数据中心-专题统计-债券报表-债券发行-可转债转股') with no explicit verb or action. It implies the tool returns convertible bond stock conversion data, but it reads as a label rather than a clear statement of purpose. It does not distinguish itself from sibling tools like bond_cov_issue_cninfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 preferred use cases, context, or exclusions, leaving the agent without direction to select among many similar bond issuance 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to repeat safety. It adds useful context beyond annotations: the data source (currencyscoop.com), the need for an api_key (with instructions), and the c_type restriction. However, it does not explain behavior like pagination, rate limits, or what 'Latest data' precisely contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact but not well-structured. It mixes a noun-phrase intro, a URL, and docstring-style param/return blocks. Type information (e.g., ':type c_type: str') is redundant with the schema and adds noise. It is acceptable but not ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only two simple parameters, the description should clarify what the returned DataFrame contains. The phrase 'Latest data of base currency' is vague, and there is no base currency parameter, making the intended result unclear. The api_key and c_type parameters are explained, but the core purpose and return structure are not adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains c_type (only 'fiat' works) and api_key (where to find it, use as password), which adds meaning beyond the bare schema. However, it does not define possible c_type values or what api_key authentication accomplishes, leaving some parameter semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'currencies data from currencyscoop.com' and 'Latest data of base currency', but there is no clear verb or definition of what the tool actually returns. It does not distinguish from sibling tools like currency_latest or currency_history, and the intended output (list of currencies vs. exchange rates) is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 sibling tools or scenarios where this would be preferred. The only constraint noted is that c_type supports only 'fiat', but this is a parameter limitation, not usage guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a source URL and the return type (pandas.DataFrame), but does not disclose behavioral traits like data scope, pagination, or potential scraping limitations. It adds minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the opening line and the :return value are identical ('郑州商品交易所-交割配对'). It includes a URL and a docstring-style param section, which is useful, but the repetition wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains, but it only repeats the tool name in both the opening and :return sections. It lacks any detail about columns, data content, or behavioral scope, making it insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It documents the date parameter as '年月日' (year-month-day) and type str, and the schema default '20210106' hints at the expected format. However, it lacks explicit format specification and constraints, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a noun phrase '郑州商品交易所-交割配对' that restates the tool's title and name without an explicit verb or explanation of what '交割配对' means. It provides a source URL but does not clarify the tool's function beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as futures_delivery_match_dce or futures_delivery_czce. The description only documents the date parameter and gives no context about appropriate use cases.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear without description support. The description adds that it returns a pandas.DataFrame, which is mildly useful, but it does not disclose data freshness, response structure, or any operational constraints. This is minimal but non-redundant value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and uses a standard docstring format, but the headline sentence duplicates the title and the long embedded URL adds noise without functional value for an AI agent. It is not bloated, but the structure could be more informative by replacing the URL with a clearer explanation of the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining the return data. It only states '规模对比' (scale comparison) and 'pandas.DataFrame', leaving the columns, row structure, and meaning vague. The purpose ambiguity further reduces completeness. For a simple one-parameter read-only tool, it should at least clarify what 'scale comparison' returns and how the symbol parameter shapes the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter 'symbol'. It does so by stating ':param symbol: 股票代码' (stock code) and type str, which gives basic meaning to the parameter. However, it lacks format details (e.g., 5-digit code, leading zeros) and does not explain how the symbol relates to the returned scale comparison. This is a partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the title repeated ('东方财富-港股-行业对比-规模对比' = East Money - HK Stocks - Industry Comparison - Scale Comparison). It lacks a verb or clear action, leaving ambiguous whether it retrieves scale data for a single stock, compares multiple stocks, or something else. It does specify the domain (HK stock industry comparison) but fails to distinguish itself from sibling comparison tools like stock_hk_valuation_comparison_em or stock_hk_growth_comparison_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 are many sibling comparison tools (valuation, growth, scale) and the description offers no context or exclusion criteria. The agent is left to infer usage solely from 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. However, the description adds no additional behavioral context beyond the URL and return type. It does not disclose what data is returned, whether the symbol filter changes the output structure, or any rate limits or source specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, but it includes redundant lines such as ':return:' and ':rtype:' which say the same thing. It is a bare docstring with some repetition and lacks a polished, front-loaded summary. It earns a middling score for being short but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description has the full burden of explaining what the DataFrame contains. It fails to do so—an agent cannot know whether this returns news items, stock codes, or price data. The meaning of the symbol parameter is also under-specified, making the tool incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does provide the allowed values '全部' and '重点' which are absent from the schema, but it does not explain what these values mean. The type declaration duplicates the schema, and the parameter name 'symbol' remains ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a label '财联社-电报' (CLS Telegram) with a URL, lacking any action verb or explicit statement of what the tool does. The tool name suggests global stock info from CLS, but the description does not confirm this or differentiate it from sibling tools like stock_info_global_em or stock_info_global_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of alternatives, use cases, or prerequisites. The URL is contextual but does not help an agent decide between the many stock_info_global_* 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds a return type (pandas.DataFrame) and a reference URL, but does not disclose behavioral details such as the DataFrame's columns, time granularity, intraday period covered, or any rate limits. This is minimal added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with only essential lines: title, URL, param, type, return, rtype. It avoids lengthy prose and each line serves a purpose. However, the lack of a main sentence makes it feel more like metadata than a human-readable explanation, preventing a score of 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description should explain what the returned DataFrame contains, the intraday interval, and any data limitations. It only states '分时数据' (intraday data) and 'pandas.DataFrame', leaving the agent uncertain about columns, time range, and whether it covers real-time or historical data. The URL is not explained either.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It defines 'symbol' as 股票代码 (stock code), which is a translation of the parameter name but adds little meaning. It does not explain the expected format (e.g., exchange prefix, leading zeros), even though the example URL suggests a market prefix ('0.000001'). The default '000001' offers some hint, but the description fails to clarify edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the source (东方财富/Eastmoney) and data type (分时数据/intraday data), which identifies the tool's core function of fetching intraday stock data. However, it lacks a clear verb (e.g., 'retrieves', 'gets') and does not differentiate this tool from similar sibling tools like stock_intraday_sina or stock_zh_a_hist_min_em, which also deal with intraday/minute data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 alternative data sources or tools. The description simply lists a parameter and return type without any contextual usage instructions, prerequisites, or exclusions. The agent receives no help in deciding whether to invoke this tool over its many 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only a URL and the return type (pandas.DataFrame), but does not disclose behavioral details such as date format expectations, data granularity, pagination, or potential limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a clear docstring structure with a source line, URL, and param/return sections. It is not verbose, but the parameter descriptions are mostly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, so the description should describe the returned DataFrame's contents. It only says '龙虎榜详情' without listing columns, aggregation level, or how it differs from related LHB tools. The tool appears simple, but the lack of output details leaves agents guessing about the structure and applicability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description's param docs restate 'start_date: 开始日期' and 'end_date: 结束日期', which adds little meaning beyond the parameter names. It does not mention the expected date format (e.g., YYYYMMDD) or any constraints, despite the schema defaults hinting at the format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '东方财富网-数据中心-龙虎榜单-龙虎榜详情' with a URL, but it lacks a clear action verb and does not specify what the '详情' includes. It is difficult to distinguish from sibling LHB detail tools like stock_lhb_stock_detail_em or stock_lhb_stock_detail_date_em, making the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus alternative LHB tools, no prerequisites, and no exclusions. The description simply states the resource name and parameters without contextual direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal extra context (source URL, return type as DataFrame) but does not disclose behaviors like date handling, error cases, or data scope. Since annotations cover the core aspects, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but it is poorly structured for an agent. It repeats the title, then provides a URL and docstring. There is no front-loaded purpose sentence, and the format is more like a raw function docstring than a clear tool description. It is not overly verbose, but it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool name includes 'date' but the input schema only has 'symbol' with no date parameter. The description does not explain how the date is determined or whether the tool returns data for a specific date. There is no output schema, so the return structure is unknown. Given the ambiguity and missing context, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (symbol) with no description (0% coverage). The description only states '股票代码' (stock code), which is redundant with the parameter name. It does not explain the expected format (e.g., leading zeros, exchange prefix), provide examples, or clarify how the symbol relates to the 'date' aspect of the tool. This is insufficient compensation for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a label: '东方财富网-数据中心-龙虎榜单-个股龙虎榜详情-日期' (East Money, Dragon Tiger List, Individual Stock Detail, Date). It lacks a clear verb or explicit statement of what the tool does (e.g., 'fetches the historical LHB detail for a given stock'). The title is repeated but adds no functional clarity, and it does not differentiate from sibling tools like stock_lhb_stock_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios, prerequisites, or exclusions. The URL and param are given but no context on how this fits into a workflow or why one would choose this over other LHB-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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the URL and return type but does not disclose additional behaviors like rate limits, authentication needs, or handling of invalid inputs. It also contains a typo where end_date is described as '开始时间' (start time), which is misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with URL, parameters, and return type. It is reasonably compact but lacks a concise opening sentence and contains a long list of category choices. It is acceptable but not optimally organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters and no output schema, the description must clearly explain the return value and usage. It only says '指定 symbol 的数据' (data for specified symbol), leaving the result structure and semantics ambiguous. It also does not explain how start_date/end_date work or what the tool is intended for beyond the title.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides Chinese labels for all six parameters and enumerates choices for market and category, which compensates for the schema lacking descriptions (0% coverage). However, the labels are often terse or tautological (e.g., 'keyword: 关键词'), and the date format is not specified, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks an explicit verb or clear statement of what the tool does. It provides a Chinese title and a URL, then lists parameters, but the action (e.g., querying disclosure reports) is only implied. It does not differentiate from siblings like stock_notice_report or stock_zh_a_disclosure_relation_cninfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no exclusions. The description is purely parameter documentation with no contextual usage information.
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?
While annotations already declare readOnly, idempotent, and non-destructive behavior, the description introduces ambiguity by specifying ':return: pandas.DataFrame' but showing a sample output that is clearly a pandas Series (with 'Name: RV, Length: 5810, dtype: float64'). It also mentions multiple RV estimates (5-min and 15-min) without clarifying what the actual output structure is, creating confusion about the 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.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose, containing a large block of website copy including references, methodology details, and data cleaning information that is irrelevant for an agent invoking the tool. It is not front-loaded with a crisp summary, and the repeated sections make it difficult to parse quickly. Only the param/return snippet and the objective sentence are useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter and no output schema, the description should clearly define the return value and parameter constraints. It fails to do so—the return type is ambiguous (DataFrame vs Series), the symbol format is undefined, and the data coverage limitations (e.g., US equities after 2007) are not explicitly stated. The sample output helps but is inconsistent with the declared return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'symbol' with no description (0% coverage). The description only says ':param symbol: str 股票代码' (stock code), which adds minimal meaning. It does not explain the expected format (e.g., US ticker vs. numeric code), valid symbols, or how the default '39693' is used, leaving the agent to guess what value to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'up-to-date daily annualized realized volatilities for individual stocks, ETFs, and future contracts' from the Risk Lab website, which is a specific resource. The title and sample output reinforce this, but it lacks an explicit comparison to sibling RV tools (e.g., article_oman_rv), so it does not fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus other RV tools or when not to use it. The description implies it is for realized volatility data, but does not state any context, exclusions, or alternatives, leaving the agent to infer usage from the data source and methodology.
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 already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. However, the description adds little beyond a URL and return type. It introduces phantom 'sector and indicator' fields that don't exist in the schema, and doesn't disclose pagination behavior, data scope, or any limitations beyond the page parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a useful URL and parameter doc, but the structure is not front-loaded with a clear purpose sentence. The return statement about 'sector and indicator' is misleading and wastes a sentence, reducing overall clarity despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains, but it doesn't describe columns, rows, pagination size, or any filtering beyond the page number. The incorrect 'sector and indicator' reference makes the tool's behavior incomplete and potentially misleading for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'page' parameter with 0% description coverage. The description does clarify that page is a numeric page number, but this contradicts the schema's string type. It also references 'sector' and 'indicator' which are not parameters, adding confusion. The description only partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the NAFMII registration system and provides a URL, but lacks a clear verb like 'query' or 'list'. It mentions returning 'data for specified sector and indicator' which is misleading because the only parameter is 'page'. This provides a general sense of resource, but doesn't clearly distinguish from other bond 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description is essentially a docstring with no context about use cases, prerequisites, or exclusions. It doesn't mention any sibling tools or when this NAFMII source would be preferred.
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?
The description discloses the return type (pandas.DataFrame) and a source URL, but it does not describe any behavioral traits beyond the read-only, idempotent, and non-destructive annotations already provided. It fails to mention what columns, time periods, or data scope the returned DataFrame contains. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes a useful URL and return type, but the first line '艺恩-艺人-艺人商业价值' is redundant as it essentially duplicates the tool name. The structure has some wasted text, lowering the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool, the description still leaves the output vague – '艺人商业价值' does not specify what data is actually included. With no output schema, the description would need to explain the returned DataFrame's structure to be complete, but it does not. The annotations cover safety but not the data content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (empty input schema), so the baseline is 4. The description does not need to explain parameters, and nothing is missing regarding parameter semantics. The mention of the return type is not directly relevant to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description primarily restates the tool name as '艺恩-艺人-艺人商业价值' and repeats it in ':return: 艺人商业价值'. It lacks a verb or clear operation statement such as 'retrieves' or 'queries'. The URL provides a source but does not clarify what the tool does. This is essentially a tautology of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or how it compares to alternatives. It does not mention any use cases, prerequisites, or distinctions from similar tools like online_value_artist. The rubric marks 'no guidance' as a 2.
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 already declare the tool read-only, idempotent, and non-destructive, so the bar is lower. The description adds the API key requirement and pandas DataFrame return type, but it also contradicts itself by saying 'Latest data' while supporting a specific date, muddling the actual behavior. It does not disclose rate limits, error handling, or data availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a docstring-style block with a link and parameter documentation. It is reasonably concise but the structure is fragmented: the summary line is vague and the link to documentation could be relocated. The parameter section is useful but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description is insufficient. It fails to clarify that this is historical data (despite the name), describe the structure of the returned DataFrame, or differentiate from sibling tools like currency_latest and currency_time_series. The return type is mentioned but not the columns or frequency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden for parameters. It explains base, date (with example format), symbols, and api_key (including where to find it), which adds real meaning beyond the bare schema. However, it does not specify the format for symbols (e.g., comma-separated) or clarify whether api_key is mandatory, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Latest data from currencyscoop.com' but the tool is named currency_history and accepts a date parameter, implying historical data. There is no specific verb like 'fetch' or 'retrieve', and it does not distinguish itself from siblings like currency_latest or currency_time_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 explain whether this is for historical rates, current rates, or how it differs from currency_latest or currency_time_series, leaving the agent with no selection criteria.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. However, the description adds minimal behavioral context—it provides a source URL and return type but does not disclose potential volume, pagination, or coverage details. It neither contradicts the annotations nor meaningfully enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It includes a URL and a docstring-style return annotation, but the primary title line is essentially a restatement of the tool name and adds little value. It is not front-loaded with a purpose statement, so the brevity does not help usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description is the only source of information about what the tool returns. It merely provides a URL and '规模变动' (scale changes) with a DataFrame type, but does not describe the data's structure, scope, or any caveats. An agent would not know what rows/columns to expect or how the data is organized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers 100% of the parameter space by definition. The description does not need to explain parameters. The baseline score of 4 for zero-parameter tools is appropriate, as no additional semantic guidance is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a label-like path '天天基金网-基金数据-规模份额-规模变动' rather than a clear verb+resource statement. It mentions the return type '规模变动' (scale changes) but does not explicitly say the tool fetches or returns this data. It also does not differentiate from sibling fund tools like fund_aum_hist_em or fund_scale_close_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative fund data tools. The description lacks any mention of use cases, exclusions, or alternatives, leaving the agent to infer from the name alone. The sibling list is extensive but no comparison is 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?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds only a source URL and return type, but no behavioral caveats such as date format requirements, data availability constraints, or potential errors. It does not contradict annotations, but adds minimal value beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and avoids wordiness, but it follows a rigid docstring template with a title, URL, and param/return lines. It lacks a clear one-sentence summary or examples, making it minimally adequate rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what data is returned, but it only states 'exchange daily trading data' and pandas.DataFrame. It does not list columns, contract scope, or data granularity, leaving the agent without enough detail to understand the tool's full output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter documentation is 'date: 交易日' (trading day), which merely restates the field name without specifying format (e.g., YYYYMMDD), valid ranges, or meaning beyond the default value. This does not add meaningful semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves daily trading data from the China Financial Futures Exchange (CFFEX), with a source URL. However, it does not distinguish itself from similar sibling tools like get_cffex_daily or futures_settle_cffex, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists a parameter and return type, with no mention of prerequisites, exclusions, or alternative tools. Usage context is entirely absent.
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?
The description adds only a source URL and a DataFrame return type. It does not disclose what columns or time period the DataFrame contains, whether it is historical or current, or any other behavioral traits. Annotations already cover read-only and idempotent safety, so the description's minimal extra information is insufficient for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the same phrase '50ETF 期权波动率指数 QVIX' appears as the first line and again in the ':return:' section. The URL is a useful addition, but the layout is awkward and the repetition wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should compensate by describing what the returned DataFrame contains and the data frequency. It does not. It also fails to clarify that this is the daily (non-minute) version, which is important context given similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete. The description does not need to explain parameter meanings, and the absence of parameters makes this dimension not a concern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool's name/title: '50ETF 期权波动率指数 QVIX' appears verbatim from the annotations. It lacks an action verb or explicit statement of what the tool does, aside from the docstring's ':return:' line indicating it returns the index. This is closer to a tautology than a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this is the daily (non-minute) variant, nor does it distinguish it from sibling tools such as index_option_50etf_min_qvix or other QVIX indices.
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 already declare read-only, idempotent, non-destructive behavior. The description adds a source URL and return type, but no behavioral context such as rate limits, data coverage, or potential performance implications. It adds minimal value beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (only a title, URL, and return type), so it is concise. However, it is not well-structured; the docstring format mixing a URL with :return: and :rtype: is awkward, and the title is redundant. It is under-specified rather than merely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description provides minimal context: it names the index, gives a source URL, and states the return type. It does not explain what data is actually returned (e.g., columns, time period, frequency) or how this index relates to other macro indicators. For an agent, this is insufficient on its own to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 (100% coverage). The description adds no parameter semantics, but with no parameters this is not a gap; a baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially '物流景气指数' (logistics prosperity index), which is just the title. It includes a URL and return type docstring, but lacks an explicit verb like 'get' or 'query'. It restates the tool's name rather than clearly describing its function, and does not distinguish it from sibling macro 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/5Does 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 (e.g., other macro indicators like macro_china_pmi). No context, prerequisites, or exclusions are provided, so the agent gets no help in selecting this tool over 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds little behavioral context, such as data source reliability, update frequency, or any caveats. The URL is present but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the title and URL, but it lacks meaningful explanatory content. The format is clear (title, URL, return/type lines) but almost every element is redundant with the name or the schema. It is concise but not informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with no parameters and good annotations, the need for extensive description is reduced. However, the description still does not explain what data exactly is returned (e.g., historical series, current value), the frequency, or the specific source beyond a bare URL. It feels incomplete even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter burden. The description adds a return type and URL, which is acceptable for a parameterless tool. The baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name ('菜篮子产品批发价格指数') with a URL and return type. There is no explicit verb indicating an action like 'fetch' or 'retrieve', so it fails to clearly state what the tool does beyond repeating its name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of scenarios, comparisons with sibling macro indices, or exclusions. The description merely states the data source and return type.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds only the return type (pandas.DataFrame) and a URL, but no behavioral traits such as required authentication, rate limits, or coverage limitations. Since the schema lacks an output description, the return type is mildly helpful, but overall the description adds little beyond what annotations and schema already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and thus concise, but its structure is fragmented: a Chinese title, a URL, then a docstring block. It lacks a front-loaded clear sentence stating the tool's primary function. The information is present but not organized in a way that makes it immediately scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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, read-only), the description covers the basic inputs and return type. However, it does not contextualize the data source, the meaning of the default value (600009), how this relates to other dividend tools, or what columns/fields the returned DataFrame contains. Without an output schema, this omission is significant for an agent deciding whether the tool meets its needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's param docstring says 'symbol: 股票代码' (stock code), which duplicates the schema's parameter name and default value. It does not explain the format, required length, exchange, or any example. With schema description coverage at 0%, the description should compensate, but it only restates the obvious. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (historical dividends for an individual stock from cninfo) but lacks a clear action verb. The title '巨潮资讯-个股-历史分红' is essentially repeated, and while the intent is evident, it does not explicitly say 'retrieve' or 'get'. It distinguishes the data source but does not differentiate from sibling tools dealing with dividends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 competing tools. The URL is given but not explained as a reference. The intended use case (fetching historical dividends) is only implicit from the title.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds no behavioral context beyond the fact that it returns a pandas DataFrame. It does not mention what the DataFrame contains (e.g., columns, date range), potential pagination, rate limits, or any notable edge cases. No contradiction with annotations, but minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of a title, URL, and return type. It is front-loaded with the title and has no fluff. However, it is under-specified, which is a completeness issue rather than a conciseness issue. The structure is logical but could include a brief sentence describing the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description still lacks essential context such as what specific fields or time periods the data covers, the format of the returned DataFrame, or any usage notes. The URL provides a reference but the description alone is not enough for an agent to understand the tool's full output. It is a minimal docstring that leaves out details an agent would typically need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 since there are none. The URL provides a source reference, but that is not parameter-related. This is acceptable for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a label: '东方财富网-数据中心-股东大会' (East Money Network - Data Center - Shareholders' Meeting) followed by a URL and return type. It lacks an explicit verb like 'get' or 'fetch', and the resource is just a noun phrase. While the name and title imply it retrieves shareholder meeting data, the purpose is not clearly stated as an action. It does not distinguish itself from sibling tools beyond naming the specific data category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any prerequisites, scenarios, or exclusions. The description is purely declarative with no context on how this fits into a data-retrieval workflow.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and the return type (pandas.DataFrame), which are useful behavioral cues. However, it does not explain what the DataFrame contains or any potential quirks, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, but it is structurally fragmented, consisting of a title, URL, and return annotations rather than a coherent descriptive paragraph. It avoids verbosity but lacks a clear explanatory sentence, making it less effective for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns a DataFrame about '抱团操作实力' but the description does not explain the data's content, columns, or meaning. With no output schema, the description carries the full burden, which it fails to meet. The URL provides the source but not the semantic details necessary for understanding what the returned data represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to clarify. Per the rubric, a zero-parameter tool receives a baseline score of 4. The description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially repeats the tool's title ('同花顺-数据中心-营业部排名-抱团操作实力') and provides a URL and return type, but does not clearly state the tool's function. It fails to differentiate from closely related siblings like stock_lh_yyb_capital or stock_lh_yyb_most, leaving the agent uncertain about what specific data this tool provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. No usage context, exclusions, or comparisons to sibling tools are provided. The agent cannot determine the appropriate scenario for selecting this tool over other stock_lh_* or stock_lhb_* options.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no extra behavioral traits: it only mentions a return type of pandas.DataFrame and a website URL, without disclosing rate limits, pagination, authentication needs, or any quirks of the underlying API. Relative to the annotations, the description contributes minimal 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no fluff: it gives the title, URL, and two parameter definitions. Every line serves a purpose. However, the structure is flat and not well organized; it reads as a single block of Chinese text plus parameter docs, which could be clearer with separators or an explicit summary. Still, it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 incomplete. It omits the date format required for start_date/end_date, does not explain what columns the returned DataFrame contains, and provides no differentiation from several sibling tools on restricted share releases. The presence of annotations and the simple schema lower the burden, but the missing date format and usage context are critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two string parameters with defaults but no descriptions (coverage 0%). The description merely restates the parameter names and types in Chinese ('开始时间'/'结束时间') without specifying the required date format (e.g., YYYYMMDD), the valid range, or whether filtering is inclusive. The default values in the schema hint at the format, but the description does not clarify it, leaving critical ambiguity for an agent to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the tool's title '东方财富网-数据中心-限售股解禁-解禁详情一览', which is a noun phrase describing a list of restricted share unlock details. It clearly identifies the resource (restricted share unlock details) but lacks an explicit action verb like 'get' or 'list', and does not differentiate it from sibling tools such as stock_restricted_release_summary_em or stock_restricted_release_queue_em. Thus it is more than a tautology but still not a fully specified 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/5Does 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 provides the source URL and parameter documentation, without mentioning any conditions, prerequisites, or exclusions. It neither states when this tool is appropriate nor names any related tools for alternative data sources.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds minimal behavioral context beyond the source URL and return type. It does not disclose date format expectations, pagination, or data scope, which would be valuable for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and not verbose, but it is poorly structured: it mixes a title, a raw URL, and docstring-style lines in a way that is not front-loaded or scannable. The first line reads like a page title rather than a clear description of tool behavior. It is brief but the organization detracts from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description should still clarify what data is returned and how the date parameter works. It fails to reconcile the conflict between '行业商誉' (industry goodwill) in the title and '个股商誉明细' (individual stock goodwill details) in the return, and it does not describe the output columns or date range. This is insufficient given the large sibling toolset where differentiation is critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single 'date' parameter with a default but no description (0% schema description coverage). The description says the date is '参考网站指定的数据日期' (the data date specified on the website), which adds a slight hint but still does not specify the expected format (e.g., YYYYMMDD) or any constraints. The description only partially compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a concrete resource: East Money's goodwill data page (行业商誉) with a URL, and states that it returns a pandas DataFrame of 个股商誉明细. However, it lacks an explicit action verb like 'get' or 'list,' and the return description ('个股商誉明细') conflicts with the title ('行业商誉'), creating ambiguity about whether this tool returns industry-level or individual-stock goodwill 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/5Does 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 simply gives a source URL and parameter docstring. With many sibling tools covering similar stock/goodwill data (e.g., stock_sy_em, stock_sy_jz_em), the absence of any differentiation makes it hard for an agent to select this tool correctly.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that the return type is pandas.DataFrame and the return content is '公司规模', which is a minimal addition. It does not disclose any behavioral traits such as network dependency, performance characteristics, or handling of invalid symbols. No contradiction with annotations, but little extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is not well-structured. It consists of a title, a URL, and type annotations mixed across lines. There is no complete sentence, and the structure is fragmented. It is under-specified rather than elegantly concise, so it does not earn a higher score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is still incomplete. It lacks critical context such as the expected format of the symbol, the specific data fields returned, and how this tool fits into the broader set of comparison tools. The URL provides a source reference but does not explain the data. The description leaves the agent with substantial ambiguity about how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to explain the symbol parameter. It merely states ':type symbol: str', which repeats the schema's type declaration. The default value 'SZ000895' in the schema hints at the format, but the description itself provides no semantic meaning, no format explanation, and no example of valid values. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title '东方财富-行情中心-同行比较-公司规模' clearly indicates this tool provides company scale (公司规模) comparison from Eastmoney's market center. It distinguishes from sibling tools like stock_zh_growth_comparison_em and stock_zh_valuation_comparison_em by focusing on scale. However, it lacks an explicit verb like 'get' or 'fetch', making it a noun phrase rather than a full functional 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The bare title and URL offer no contextual hints about selection criteria, leaving the agent to infer usage from the tool name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the data source URL and output type (pandas.DataFrame) but no additional behavioral details such as pagination, rate limits, or data coverage. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact but front-loads a verbose source path and URL that are not essential for invoking the tool. The parameter and return documentation are useful, yet the overall structure reads as a docstring rather than a purpose-driven description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters and no output schema, so the description should clarify output columns, date coverage, and uniqueness among siblings. It only states the return is a 国债指数 (treasury bond index) DataFrame, which is insufficient for an agent to understand the data without additional inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for parameters, so the description must compensate. It lists allowed values for indicator (full price, net price, wealth) and period (various maturity ranges), which is helpful, but it does not explain the meaning of each indicator or the structure of the returned data. This is partial compensation but leaves semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description consists of a Chinese source path and return type with no explicit verb, so it only implies the tool retrieves the ChinaBond Treasury Bond Index. It names the resource precisely but does not explicitly state the operation or differentiate it from sibling bond index tools like bond_composite_index_cbond or bond_index_general_cbond.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. Sibling tools include multiple bond index tools, but the description provides no selection criteria, exclusions, or context to help an agent choose this specific treasury index 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns monthly data and that date must be between '2015-01' and now, which is useful. However, it does not explain what columns or factors are included, and the paper abstract at the top is not behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are an academic abstract that is irrelevant to using the tool, pushing the operational docstring to the end. This is not concise or front-loaded; it wastes the user's attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return structure. It only says 'Monthly Data' with no column details. The tool's relationship to FRED-MD factors and diffusion indexes is hinted but not specified. The single parameter is documented, but the overall data shape and semantics are unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a string 'date' with no description, while the description provides a format example ('2020-03'), a valid range ('2015-01' to now), and the type. This significantly clarifies the parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a paper abstract rather than a clear verb+resource statement. The only functional hint is ':return: Monthly Data', but the tool's action (fetch/retrieve) is never explicitly stated. The name fred_md implies FRED-MD dataset, but the description lacks a direct statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention sibling tools like fred_qd or other macro data tools, nor any exclusions or prerequisites. The date parameter example is the only context, but it doesn't help with tool selection.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety traits. The description adds only the source URL and return type, with no additional behavioral context like data freshness, rate limits, or output structure. It does not contradict annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and contains only essential elements: title, source URL, return description, and type. It is appropriately short for a zero-parameter tool, though it may be under-specified. Still, it is concise without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema defined, the description should clarify what the returned DataFrame contains and its scope (e.g., all LOF funds, specific columns). It only states :rtype: pandas.DataFrame, leaving the agent unclear about the actual data structure. The URL hints at a grid list but does not confirm coverage or format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is effectively 100%, so the description has no parameter burden. The baseline of 4 applies, and no further elaboration is needed since there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name and title ('东方财富-LOF 实时行情') with only a URL and return type added. It lacks a verb and does not clearly distinguish itself from sibling tools like fund_etf_spot_em, making it closer to a tautology than a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 gives no context for selection among the many spot-price tools (e.g., fund_etf_spot_em, stock_zh_a_spot_em), nor any exclusions or preferred scenarios.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds a source URL and return type, which is some useful context. However, it does not describe data shape, potential size, or any other behavioral traits, so the added transparency is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (4 lines) and includes relevant information: URL, return value, and return type. The first line repeats the title, which is slightly redundant, but overall it is efficient and front-loaded with the source URL. It earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter explanations, the description should clarify what the returned DataFrame contains. It only says '融合指数' (fusion index) without explaining its meaning, columns, or granularity. The URL provides a reference but is not self-contained. This is insufficient for a data-returning tool, even with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has no properties (100% coverage by default since nothing needs documenting). The description does not need to explain any parameters. Baseline 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool's title (财新数据-指数报告-融合指数) and simply states the return value is 融合指数 with a URL. It does not explain what the fusion index is or what data it contains, making it largely a tautology of the name. No clear verb or resource description distinguishes it from sibling index tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There are many sibling index_*_cx tools (e.g., index_ai_cx, index_si_cx) with similar naming, but the description does not mention any differences or appropriate usage scenarios, leaving the agent without any decision support.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds a return type (pandas.DataFrame) and a source URL, which is some value beyond annotations. However, it does not disclose behavioral details like data frequency, historical range, or update schedule, so it only partially enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: the first line repeats the title, and the ':return:' line repeats the same phrase. The URL adds some value but is not accompanied by any explanatory structure. It is under-specified rather than concise, with no clear sentence structure or front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling QVIX tools, this description is incomplete. It does not mention that it likely provides daily QVIX data versus the _min_ variants, nor does it specify any time range, data source characteristics, or update frequency. The presence of no output schema increases the need for descriptive detail, which is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects this with an empty properties object and 100% coverage. With no parameters, the description doesn't need to explain parameter semantics, and the baseline of 4 applies. The description could explicitly state 'no parameters' but that is already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: '500 ETF 期权波动率指数 QVIX' restates the tool name and title without any verb or action. It identifies the data resource but does not describe what the tool does beyond that, and it does not differentiate this from sibling tools like index_option_500etf_min_qvix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 gives no context about daily vs. minute data, or how this differs from the many sibling QVIX tools. There is no mention of exclusions or related 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type (pandas.DataFrame), providing some value beyond annotations, but lacks details on data coverage, frequency, or quirks. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but not well-structured: it is a title, URL, and docstring fragments rather than a clear sentence. It is not verbose, but it lacks front-loaded purposeful phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter fetch tool, the description provides the source and return type but omits what specific money supply data is returned (e.g., M0, M1, M2), historical coverage, or column structure. No output schema exists, so the description should carry more weight but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description has no parameter burden. Baseline for 0 parameters is 4, and no additional semantic detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is '东方财富-货币供应量' which translates to 'Eastmoney - Money Supply', essentially restating the tool name in Chinese. It includes a URL and return type but no verb or scope, making it near-tautological and not distinguishing it from sibling money supply tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like macro_china_m2_yearly or macro_china_supply_of_money. It only gives a data source URL without any contextual direction.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond repeating the title and return type, omitting details such as data scope, freshness, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant elements—the title is repeated, and the return type is stated in a stilted ':return:' format. While it is concise, it could be better structured to convey actual value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what data the tool returns. It only says '期权风险分析' without enumerating the metrics, underlying contracts, or data granularity, making it inadequate for an agent to anticipate the output content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The empty schema is fully described trivially, and there is no parameter information needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an Eastmoney data source for options risk analysis and indicates it returns a pandas DataFrame. However, it merely restates the title and does not specify what 'risk analysis' includes, nor does it distinguish this tool from sibling option tools like option_value_analysis_em or option_risk_indicator_sse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 alternative option data tools. The description only gives a URL and a generic return type, leaving the agent without any basis for selecting this tool over its many 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, and the description adds no behavioral traits beyond that. It mentions the URL and return type but does not disclose details like rate limits, authentication, or data update frequency. While it does not contradict annotations, it adds minimal behavioral context, so the score is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and avoids unnecessary verbosity, but it is structured as a fragment: a title, a URL, and docstring lines. It is not a coherent sentence, and the layout could be cleaner. It earns its place, but the structure is suboptimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description carries the responsibility of explaining what the tool returns. It states the return type (pandas DataFrame) and the general subject (market congestion), but it does not describe the columns, date range, or any other details about the data. This is adequate for a simple zero-parameter retrieval but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). There is nothing to explain about parameters, so the baseline score of 4 applies. The description does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool's name ('乐咕乐股-大盘拥挤度' / 'LeGuLeGu - Market Congestion') and includes a URL and return type. It lacks an explicit verb like 'get' or 'retrieve', making it not much more than a labeled resource. It does identify the resource (market congestion data) but does not clearly state what action the tool performs, so it is close to a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any similar tools or exclude any scenarios. There is no explicit context or comparison, so an agent has no basis for choosing this tool over siblings beyond the name itself.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a source URL and return type (pandas.DataFrame), but gives little additional behavioral context such as rate limits, error behavior, or what the DataFrame contains. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a long, redundant title repeated in consecutive phrases ('东方财富分析师指数-东方财富分析师指数'), which wastes space. While the docstring sections are structured, the overall text is not concise or front-loaded with key information, making it harder for an agent to quickly grasp the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify what the returned DataFrame contains, but it only repeats the index name without describing columns, granularity, or meaning. The URL and parameter range are present, but missing usage context and return-value details leave the tool under-specified for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'year' parameter (0% coverage), but the description's docstring explains it accepts a string from 2015 to present. This provides meaningful guidance on the expected format and valid range, effectively compensating for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a noun phrase ('东方财富分析师指数') repeated twice, with a URL and docstring, but no verb stating what the tool does. It restates the tool name rather than specifying an action like 'queries' or 'returns', so it fails to clearly convey the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides a parameter range and return type, with no mention of use cases, prerequisites, or contexts where this tool is appropriate. It also does not differentiate it from 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal insight: the source URL and that the return is a pandas DataFrame. It does not disclose data scope, columns, pagination, or any other behavioral traits. The added value beyond annotations is very low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is under-specified and lacks a clear sentence structure. It reads like a docstring with a URL and return annotation, not a purpose-built tool description. It could be improved with a clear verb and a brief explanation of the data content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (zero params, no output schema), the description is still incomplete. It does not tell the agent what the DataFrame contains (e.g., columns, rating levels, time range), nor does it describe any filtering or limits. The annotations cover safety, but the description does not provide enough context for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter schema to explain. The baseline of 4 applies because no parameter documentation is needed. The description's mention of the return type is redundant with the rtype line but does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase '新浪财经-ESG评级中心-ESG评级-华证指数' with a URL and return type, which implies it fetches ESG rating data from Sina Finance for the Huazheng index. It does not use an explicit verb like 'get' or 'fetch', and it does not differentiate itself from sibling ESG tools (e.g., stock_esg_msci_sina) beyond the source name in the title. The purpose is inferable but not clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. No context about use cases, prerequisites, or distinctions from other ESG rating tools is provided. The description only supplies the source URL and return type, which does not help an agent decide when to select this 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds only a source URL and return type, with no behavioral details such as data freshness, pagination, or limitations. With annotations covering safety, the description contributes minimal extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with a title, URL, parameter, and return type. The first line repeats the title unnecessarily, but overall it is efficient and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of closely related stock_lhb_* tools, the description does not clarify what specifically '营业部统计' means or how it differs from alternatives like stock_lhb_yyb_detail_em. It lacks the disambiguation needed for an agent to confidently select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the symbol parameter, but the description explicitly lists the allowed values ('近一月', '近三月', '近六月', '近一年') and the type. This is critical for correct invocation, effectively compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's first line is identical to the title, and the return type is the same phrase (营业部统计). It does not state an explicit action or clarify what the tool retrieves beyond what the name already implies. The URL and parameter info add some context, but the core purpose remains a restatement of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many other stock_lhb_* sibling tools. No mention of alternatives, exclusions, or situational context, leaving the agent to infer usage from the name alone.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, establishing it as a safe, read-only operation. The description adds that it returns a pandas.DataFrame and the source URL, which provides some value beyond annotations, though it does not elaborate on data scope or potential quirks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and follows a clear docstring structure with :return: and :rtype:. However, the first line is redundant with the title, and the content is terse rather than informative. It earns a 4 for being compact and structurally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description is the only source for understanding the returned data. It states the return type is a DataFrame but does not describe columns, time range, or the meaning of '赚钱效应'. This leaves the agent without enough context to interpret the output or decide if it meets a user's need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is no parameter ambiguity to resolve. The schema coverage is effectively complete, and the description is not required to compensate for missing parameter documentation. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely repeats the title '乐咕乐股网-赚钱效应分析' with no verb or explanation of what the tool actually computes or returns. It does not distinguish itself from sibling stock market tools, and the term '赚钱效应' (profit effect) is left undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. No scenarios, prerequisites, or exclusions are mentioned. The URL is useful for human reference but does not clarify selection criteria for an AI agent.
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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds a return type (pandas.DataFrame) and a source URL, which provides a little extra context. However, it does not disclose behavioral traits such as whether the data is live-snapshot, how the DataFrame is structured, or any potential rate limits or authentication needs. Thus it provides partial but not rich additional behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it redundantly repeats the title in the first line and the return line. The URL is a useful reference, and the return-type annotation is informative. The structure is compact, but the redundant repetition reduces conciseness quality; every sentence does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a highly specialized bond tool with no output schema, the description leaves important gaps: it does not explain what '强赎' (strong redemption) means, what columns/fields the DataFrame contains, or how this tool differs from similarly named bond tools. The URL hints at the data source but does not make the tool self-contained for an agent. Given the tool's simplicity (no params) and good annotations, more context is still expected to make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty (100% schema coverage with no properties). The baseline for zero-parameter tools is 4, and the description offers no parameter information because none exists. It does not need to compensate for parameter semantics, so the score reflects the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a repeat of the title ('集思录可转债-强赎'), providing no additional specification of what the tool does beyond the name. The URL and return type annotation add minimal context, but the core purpose (retrieving strong-redemption convertible bond data) is only implied by the title. This is a tautology of the title, hence a low score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention use cases, preferred conditions, or exclude scenarios. Sibling tools like bond_cb_jsl (general convertible bonds) and bond_cb_index_jsl (index) suggest similar resources, but the description offers no differentiation or selection advice.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. However, the description adds no behavioral context beyond repeating the title and the date parameter. It does not disclose pagination, rate limits, data coverage, or how the date is interpreted beyond '交割日期'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but somewhat unstructured, mixing a title, a URL, and docstring-style param/return lines. It contains no fluff, but the format is purely technical and the URL is not explained. It could be more readable with a simple sentence, but it is not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return value. It only says 'returns Dalian Commodity Exchange delivery statistics as a pandas.DataFrame' without detailing columns (e.g., contract, delivery volume, delivery price) or any other output characteristics. This leaves the agent with insufficient information to anticipate the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'date' parameter with default '202312', and schema description coverage is 0%. The description's param line only says '交割日期' (delivery date) with type str, but does not specify the expected format (e.g., YYYYMM or YYYY-MM), whether it is a single month or range, or any examples. The default value hints at YYYYMM, but this is not explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource (Dalian Commodity Exchange delivery statistics) and includes the official URL. While it lacks an explicit verb like 'fetch' or 'retrieve', the combination of the tool name and description makes the function's purpose clear. It is distinguishable from sibling tools for other exchanges (e.g., futures_delivery_czce) by naming DCE explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this is for DCE (though the name implies it) or explain any exclusions. No comparison with sibling delivery statistics tools for other exchanges is offered.
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?
The annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already establish that this is a safe read-only operation. The description adds the source URL and the return type, which gives some context, but it does not disclose additional behavioral traits such as data update frequency, pagination, or any quirks. There is no contradiction with annotations, but the added info 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and not overly verbose, but it repeats the same phrase '新浪主力连续合约品种一览表' in both the title line and the :return line, which is redundant. The URL and docstring format provide structure, but the repetition wastes a little space without adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not fully specify what the returned DataFrame contains beyond the generic 'main continuous contract varieties list'. It does not list columns, describe the nature of the data (e.g., real-time vs. historical), or clarify how it differs from futures_main_sina. Since there is no output schema, the description should provide more detail to enable correct use, but it remains vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4 according to the rubric. There are no parameter details to explain, and the schema is empty, so the description is not required to compensate for missing parameter information. The description adequately covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a noun phrase 'Sina main continuous contract varieties list' that restates the tool name in Chinese without a clear action verb like 'fetch' or 'get'. It includes a return type (pandas.DataFrame) which implies data retrieval, but it does not specify the operation explicitly. It also fails to distinguish itself from the sibling tool futures_main_sina, which appears to serve 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives. It does not mention any specific use cases, prerequisites, or exclusions, leaving the agent to guess among the many similar futures-related tools. There is no guidance on when to prefer this over futures_main_sina or other spot/realtime 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context such as data granularity, rate limits, or the meaning of the DataFrame contents. It does not contradict the annotations, but provides no extra value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title and URL, followed by docstring-style param/return lines. It is not verbose, but it repeats the same '玄田数据-核心数据' phrase multiple times and the URL insertion feels abrupt. The structure is functional but not polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns a pandas.DataFrame, but the description never specifies what columns, indices, or data content the frame contains. With no output schema and a vague name, the agent cannot determine what 'core data' includes. This is especially problematic given the many similar hog data tools, making the description incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by specifying the allowed values for symbol ('外三元', '内三元', '土杂猪') and its type (str). This is crucial because the schema only shows a default value without an enum. The description adds real semantic value, though it does not explain the meaning of each pig type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially repeats the title '玄田数据-核心数据' without adding a clear verb or action. It mentions a URL and parameter choices, but never states what 'core data' actually contains or what operation is performed. This borders on tautology, relying on the tool name and title to imply 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/5Does 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 the many sibling hog-related tools (e.g., futures_hog_cost, futures_hog_supply, spot_hog_soozhu). There is no mention of use cases, exclusions, or alternatives, leaving the agent to guess when this tool is appropriate.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it returns a pandas.DataFrame and includes a data source URL, but does not disclose any additional behavioral traits such as potential delays, network usage, or column structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes a useful source URL and return type annotations. However, the opening line is redundant with the annotation title, and the formatting as code-style comments is slightly fragmented. Still, it is efficient and mostly earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with strong annotations, the description is minimally adequate but incomplete. It does not explain what 'subscribe_exchange_symbol' means in practice or specify the DataFrame columns, leaving the tool's exact output and purpose ambiguous despite its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter schema to elaborate. The description's mention of return type and table content provides baseline semantic value beyond the empty schema, matching the 0-parameter baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '将品种字典转化为 pandas.DataFrame' is nearly identical to the annotation title and fails to specify the actual action of subscribing or exchanging symbols. It mentions a resource (variety table) and return type, but does not differentiate from sibling tool futures_foreign_commodity_subscribe_exchange_symbol, which likely has a similar purpose for foreign commodities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 a conversion action and a source URL, with no context about prerequisites, typical use cases, 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL (chinamoney.org.cn) and the return type (pandas.DataFrame), which are not present in annotations. However, it does not describe the data structure, freshness, or any potential side effects like network calls, but given the annotations cover the safety profile, this partial addition warrants a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first line is a redundant repetition of the product name that is already present in the annotations title. The URL and docstring-style :return: and :rtype: lines add useful information, giving it a recognizable structure. However, the redundant line wastes space, so it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains (e.g., tenors, rates, dates), but it only repeats the curve name. It also does not provide any context about the C-Swap fixing curve's meaning or how it differs from other forex tools. This is a simple no-parameter fetcher, but the description lacks enough detail to be fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description properly does not need to explain any parameter semantics. The description adds no param details because there are none to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool's full product name (中国外汇交易中心...外汇掉期 C-Swap 定盘曲线) with no explicit verb or action. It identifies the resource but does not state what the tool does beyond returning that curve, and it does not distinguish from sibling tools like fx_swap_quote. The :return: line implies retrieval, but the main body is a noun phrase, making it a tautology of 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/5Does 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 provides only the name, a URL, and return type, with no context for which scenarios warrant calling this tool, or why it should be chosen over related fx tools such as fx_swap_quote or forex_hist_em. No exclusions or prerequisites 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?
Annotations already declare readOnly/openWorld/idempotent, and the description adds the available date range and sample output. However, the return contract is ambiguous: rtype says pandas.DataFrame while the sample shows two dataframes (symbol_df and long_short_df), and no side-effect or error behavior is discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a large, unneeded sample of 50+ rows for symbol_df and a long_short_df, making it unnecessarily long. The beginning is reasonably front-loaded with title/period, but the sample dominates the space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with no output schema, the description does not fully cover what is needed: parameter semantics are wrong and the return shape is ambiguous. The date-range hint and sample data provide some value, but an agent still cannot confidently know valid inputs or exact output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it only says 'url: 网址' (tautological) and 'date: 中文名称' (misleading). No date format, allowed values, or relationship to the stated date range is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving 总持仓分布 (total position distribution) from 奇货可查 for a given date, and the sample output shows position data. It is clear about the resource but does not explicitly contrast with sibling fund tools such as get_qhkc_fund_money_change or get_qhkc_fund_bs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only usage-relevant context is the stated date range '2016-10-10:2019-09-30' and defaults, but there are no exclusions, prerequisites, or alternative tool mentions.
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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds a source URL and return type (pandas.DataFrame), but no behavioral traits such as data updates, rate limits, or whether it returns historical or current values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title. However, it repeats the same phrase in the description, return, and rtype lines, which is slightly redundant. Overall, it is efficient for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not specify the data frequency (daily vs. minute), which is a critical gap given the existence of the sibling 'index_option_cyb_min_qvix'. It also does not clarify what data range or columns the DataFrame contains, making it incomplete for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. Per the baseline for 0 params, the description does not need to add parameter details, and it provides the return type, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource ('创业板 期权波动率指数 QVIX') and provides a source URL, but it lacks an explicit verb like 'get' or 'fetch'. It does not differentiate itself from the similarly named sibling 'index_option_cyb_min_qvix', leaving ambiguity about whether this is the daily or minute-level index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There is no mention of data frequency, time range, or any prerequisites, making it impossible for an agent to decide between this and the many other QVIX 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?
Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds a source URL (https://data.eastmoney.com/cjsj/foreign_5_0.html) and the return type as a pandas.DataFrame containing '零售销售月率', which provides some context about the data origin and output. However, it does not disclose other behavioral traits such as data frequency, time range, or any network dependency, so the added value is limited to basic source/return information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no fluff, but it is formatted like a docstring label rather than an explanatory entry: a title line, a URL, and a return annotation. It is under-specified for a functional description, yet it does present the minimal metadata efficiently. The structure is acceptable but not well-balanced; it front-loads a title that repeats the tool name instead of a clear purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (0 params, read-only, no output schema), the description is not fully self-contained. It fails to state in a clear sentence what the tool does, leaving the agent to infer from the name. It also lacks any differentiation from the large set of sibling tools covering other Australian economic indicators, and does not describe the data structure beyond a vague return label. The annotations cover safety, but the description does not provide sufficient domain context for reliable selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there is nothing for the description to explain regarding parameters. Per the rubric, a 0-parameter tool receives a baseline of 4 since no parameter documentation is needed. The description correctly omits any parameter-related content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a Chinese translation of the tool name ('东方财富-经济数据-澳大利亚-零售销售月率'), which repeats the semantics already in 'macro_australia_retail_rate_monthly'. It lacks an explicit verb or action statement, so it reads as a heading rather than a functional description. It also does not differentiate this tool from siblings like macro_australia_cpi_yearly or macro_australia_trade, all of which are similarly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many other Australian macroeconomic tools. The description provides only a URL and a return annotation, with no mention of alternatives, prerequisites, or specific use cases. The agent must infer the appropriate context solely from the tool name, which the description does not support or clarify.
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 already cover safety (readOnlyHint=true, destructiveHint=false) and idempotency. The description adds the source URL and return type (pandas.DataFrame), which are useful behavioral traits, but it does not explain data granularity, time span, or any underlying data retrieval behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but the first line redundantly repeats the title from annotations. The URL and return type provide value, yet the duplication constitutes minor waste, making it adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple with no parameters, the description does not clarify what the returned DataFrame contains (e.g., historical index values, dates, columns), what time range or frequency is covered, or what the BDTI index conceptually represents. The URL hints at East Money but leaves the output contents ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description is not responsible for explaining parameters. The baseline of 4 applies, and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description merely states '原油运输指数' (crude oil transport index), which is identical to the title, along with a source URL and return type. It does not articulate a distinct action or resource beyond the tool's name, and it fails to differentiate from similar macro indices like macro_china_energy_index or macro_china_freight_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lacks any mention of use cases, prerequisites, or comparison with 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?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description only adds the return type (pandas.DataFrame) and a source URL, without additional behavioral context such as data scope, update frequency, or potential quirks. It does not contradict annotations but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the data source and subject. It includes a URL and return type in a concise docstring format. It could be slightly improved with a proper sentence, but it avoids unnecessary verbosity and earns a high score for economy of words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description must explain what the returned DataFrame contains. It only says 'foreign exchange and gold reserves' without specifying columns, granularity, time range, or whether it returns historical or current data. This is insufficient for an agent to have confidence in what it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description correctly notes the return type, which is the only meaningful semantic information a parameterless retrieval tool needs to convey. No parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides the source (East Money) and subject matter (foreign exchange and gold reserves), but it lacks a clear verb indicating the action (e.g., 'get', 'retrieve', 'fetch'). It reads more like a title than an instruction, and it does not differentiate from similar sibling tools like macro_china_foreign_exchange_gold or macro_china_fx_reserves_yearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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, prerequisites, or comparisons to other macro tools, leaving the agent without a rationale for 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?
Annotations already state readOnlyHint, openWorldHint, and idempotentHint. The description adds only a source URL and return type, without disclosing data frequency, units, time range, or any other behavioral traits. It provides minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It is not conciseness that adds value; it omits essential information and lacks structured explanation beyond the docstring lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description is insufficient. It does not explain what data will be returned (e.g., historic time series, units, or period), leaving significant ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description indicates the return type as a DataFrame, which is helpful, but there are no parameters to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (商品零售价格指数) and provides a source URL and return type, but lacks an explicit action verb like 'retrieves' or 'returns'. It identifies the index but does not clearly differentiate from sibling macro tools beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other macro economic data tools. No alternatives, prerequisites, or context are mentioned, leaving the agent without direction on 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the source URL and a generic 'returns daily statistics' statement, but does not disclose behavioral details such as data granularity, date range constraints, or response structure beyond the return type. It falls short of the context that annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: title, source URL, and docstring blocks. It avoids unnecessary verbiage, though the title is repeated verbatim as the first line, adding a minor redundancy. Overall, it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the daily overview DataFrame contains (columns, metrics, etc.). It only says '每日统计' (daily statistics), leaving the data content unspecified. It also fails to mention how this tool relates to its SSE sibling, making it incomplete for an agent needing to decide on data coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description labels the date parameter as '交易日' (trading day), giving it semantic meaning beyond the schema's bare 'date' field. However, it does not specify the required format (e.g., YYYYMMDD) or provide examples, despite the schema default '20240626' hinting at it. With 0% schema coverage, this partial explanation merits a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is largely a title ('深圳证券交易所-市场数据-期权数据-日度概况') plus a source URL and docstring. It clearly indicates the resource (SZSE options) and scope (daily stats), but lacks an explicit verb like 'retrieves' or 'gets.' It also does not distinguish this tool from its direct sibling option_daily_stats_sse except through the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., option_daily_stats_sse for SSE), nor are any prerequisites, exclusions, or contextual conditions mentioned. The description is purely declarative and gives no decision-making support.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered. The description adds the data source URL and return type (pandas.DataFrame), which is some useful context, but it does not disclose additional behavioral traits such as data freshness, volume, or any quirks. It neither contradicts annotations nor adds rich behavioral detail, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the title-like phrase, but it includes extraneous elements like a URL and a return type that could be considered necessary but are not well integrated. It is concise but under-specified, lacking any meaningful explanation. It does not waste words, but it also does not earn its place beyond basic identification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters and output schema, the description still fails to provide a complete picture. The mismatch between the tool name and the described data (crossbred vs. backup binary sow) leaves the agent uncertain about the data's exact nature. It does not explain the data's scope, source, or limitations, making it inadequate for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter syntax or meaning since there are none. The schema coverage is trivially 100%, and no additional param-related information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and somewhat tautological, echoing the title '搜猪-生猪大数据-全国后备二元母猪' without a clear verb or action. The tool name ('spot_hog_crossbred_soozhu') does not align well with the described data ('national backup binary sow'), creating confusion about what exactly is returned. It lacks a clear statement of what the tool does, such as 'retrieve' or 'get', and does not distinguish itself from sibling tools like spot_hog_soozhu or spot_hog_lean_price_soozhu.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or exclusions. It merely provides a URL and a return type, leaving the agent without context about when this tool is 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. However, the description adds no behavioral context beyond restating the basic function; it does not disclose input validation, error handling, or return value specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose front-loaded in the first line and docstring-style parameter/return notes. However, the parameter type line duplicates schema information and adds minimal value, and the overall format is not optimized for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple code-to-market lookup, the description covers basic input and output, but the return value ('股票市场') is vague, with no mention of possible market names or whether indices are supported. Without an output schema, this is a significant gap, as agents cannot predict the exact response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has 0% description coverage, the docstring compensates by defining 'symbol' as a stock code (股票代码) of type str. This adds meaning over the bare schema, but it omits accepted code formats, market prefix conventions, and how the default '000300' is interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '输入股票代码判断股票市场' (input stock code to determine stock market), which is a specific verb+resource pairing. It is unambiguous but does not explicitly distinguish itself from sibling tools that also process stock codes, such as stock_info_a_code_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 lacks any mention of use cases, prerequisites, or exclusion criteria, leaving an agent without context for selecting it among the many stock-related 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety profile is covered. The description adds non-redundant behavioral details: the source URL (indicating the origin of data) and the return type (pandas.DataFrame). However, it does not disclose limitations, filtering behavior, or any operational caveats, so it adds only modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the data source, but the first line repeats the annotation title, which is redundant. The URL and return type lines are useful and non-repetitive. Overall, it is under-specified but not verbose; the redundancy costs it a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficiently complete for a tool with no output schema. It only states that it returns a DataFrame of '新股发行' (new stock issuance), but does not explain what columns, time ranges, or specific data points are included. It also fails to differentiate from many IPO-related sibling tools, leaving the agent uncertain about the exact content and scope of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (trivially). The baseline for no parameters is 4, and the description need not explain any input semantics. It correctly implies the tool takes no arguments and returns a complete dataset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool name/title: '巨潮资讯-数据中心-新股数据-新股发行' is identical to the annotation title. It uses a noun phrase ('新股发行') rather than a specific verb like 'retrieve' or 'list', and provides no differentiation from similar stock IPO tools like stock_ipo_summary_cninfo or stock_new_gh_cninfo. The URL and return type add slight context but do not clarify the action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides a source URL and return type, with no mention of scenarios, prerequisites, or exclusions. Unlike strong examples that explicitly name sibling tools for comparison, this description leaves the agent to infer usage context.
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 already declare readOnlyHint=true and destructiveHint=false, so the description does not need to cover safety. It adds useful context by specifying the return type (pandas.DataFrame) and source URL, but it does not disclose any behavioral nuances such as data coverage, pagination, or the evident scope inconsistency between 'all' and 'STAR Market'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not verbose, but its structure is a raw dump of a title, URL, and Sphinx-style return directives. The first line merely restates the tool name/title, which wastes space; the rest is functional but poorly organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 the presence of numerous sibling register-related tools, the description is incomplete. It does not clarify what 'all' means in contrast to stock_register_kcb, stock_register_cyb, etc., nor does it explain the exact contents of the returned DataFrame beyond 'audit results'. The internal scope mismatch further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is nothing for the description to explain. The baseline score of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the tool's name in Chinese ('东方财富网-数据中心-新股数据-IPO审核信息-全部') followed by a URL and return type. It lacks a clear verb like 'get' or 'return', and it inconsistently states '全部' (all) in the title but says the return is only '科创板注册制审核结果' (STAR Market audit results), creating ambiguity about whether this covers all boards or just the STAR Market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many related sibling tools such as stock_register_kcb, stock_register_sh, stock_register_sz, etc. The description does not explain the distinction between 'all' and the individual market-specific register tools, nor any exclusions or prerequisites.
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 already cover readOnly, idempotent, and non-destructive behavior. The description adds the return type (pandas.DataFrame) and date format constraints, which are useful. However, it does not disclose potential behaviors like error handling for invalid dates or data availability ranges beyond the start date.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but poorly structured: it starts with a category path, then a URL, then parameter/return lines. It could be more front-loaded with a clear one-sentence purpose. The URL is arguably unnecessary for an AI agent. Every line provides some info, but the ordering and formatting hurt readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 offers return type and date constraints, but it leaves key context ambiguous: what exactly '业绩报表' contains, whether the date represents the report period end or announcement date, and how it differs from adjacent tools. With no output schema, the description should clarify the data structure or at least the meaning of the date. It falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema offers no description for the 'date' parameter (0% coverage), so the description must compensate. It does so by providing explicit valid examples ('20200331', '20200630') and a lower bound ('从 20100331 开始'), which gives the agent actionable format and range information. It stops short of explaining that these are quarter-end dates, but the examples strongly imply it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a breadcrumb path ('东方财富-数据中心-年报季报-业绩快报-业绩报表') and the return type '业绩报表', which restates the tool name. It lacks a clear verb or explicit statement like 'Retrieves performance reports from East Money for a given date.' The purpose is implied but not clearly articulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter constraints (valid date formats, starting from 20100331) but offers no guidance on when to use this tool versus similar siblings like stock_yjkb_em or stock_yjyg_em. No alternatives or exclusions are mentioned.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the source URL and the fact that the return is a pandas DataFrame, but does not disclose any additional behavioral aspects such as data limitations, update frequency, or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and direct, providing the source, parameter, and return type in a compact docstring format. The URL is arguably unnecessary for an AI agent but not overly verbose. It is well-structured but lacks narrative context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description does not explain what qualifies as a 'strong stock' within the limit-up pool, nor does it differentiate from other zt_pool tools like stock_zt_pool_em, stock_zt_pool_zbgc_em, or stock_zt_pool_sub_new_em. An agent could not confidently select this tool without additional context. The rich annotations partially compensate, but the description leaves selection criteria unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents that the 'date' parameter is a trading day (交易日) and the return is a DataFrame, adding some meaning beyond the schema's type/default. However, it does not specify the expected date format (e.g., YYYYMMDD) or allowed range, leaving ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as East Money's 'strong stock pool' under limit-up quotes, with a URL and return type. It clearly states the data source and what is returned, but lacks an explicit verb (e.g., 'fetches') and does not distinguish this pool from other limit-up pool tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives. The description only provides a URL and docstring, with no mention of use cases, exclusions, or comparison to sibling tools like stock_zt_pool_em or stock_zt_pool_zbgc_em.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is reduced. Yet it adds only the source URL and Chinese parameter labels, not behavioral context like filtering semantics, pagination, or optionality of parameters, beyond the generic return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a docstring that repeats the title string, includes a URL, and lists parameters without a concise summary sentence. It is not front-loaded with a clear purpose statement, making it less efficient than a well-structured natural language description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, the description fails to explain parameter optionality, result format, or typical usage. It only provides the return type as 'pandas.DataFrame' and a vague '信息查询结果', leaving an agent without enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides Chinese glosses for each parameter (e.g., '债券名称' for bond_name, '债券代码' for bond_code), adding semantic meaning beyond the bare schema names. However, it lacks format constraints, examples, or guidance on parameter combinations, so it only partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title '中国外汇交易中心暨全国银行间同业拆借中心-数据-债券信息-信息查询' clearly indicates a bond information query tool from ChinaMoney, providing a specific resource and implied verb. However, it does not differentiate from sibling tools like bond_info_cm_query and bond_info_detail_cm, and lacks a direct sentence stating its functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains only a URL and parameter definitions, with no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent cannot determine the intended context from the description alone.
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 already declare read-only, idempotent, and non-destructive behavior. The description adds little beyond the source URL and return type, without detailing what data is included, whether it is historical or real-time, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but repetitive, with '深证质押式回购' appearing in both the title and the return line. It is structured as a docstring but lacks a clear, front-loaded sentence stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain the return value in more detail. It only states that the return type is a pandas DataFrame and vaguely mentions '深证质押式回购', leaving the column structure and data scope unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meaning. The baseline of 4 applies because there is no parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '深证质押式回购' (Shenzhen pledged bond repo) and provides a data source URL, but lacks an explicit verb such as 'get' or 'fetch'. It distinguishes from the Shanghai sibling via the name, but the purpose is inferred rather than clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like bond_sh_buy_back_em. The description only states the data source and return type, with no contextual hints for selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and source URL, but no additional behavioral traits such as pagination, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured with param/return tags, making it easy to parse. However, the source URL is repeated twice, and the text is somewhat terse without a clear top-level purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but no output schema exists. The description does not specify the date format, nor does it describe the columns or content of the returned DataFrame. Given the absence of an output schema, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'date' at 0% description coverage. The description calls it '日期' (date) and points to a URL for obtaining the query date, but does not specify the expected format (e.g., YYYYMMDD) or valid values beyond the default '20230331' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '天天基金网-基金评级-济安金信评级' (Eastmoney Fund Network - Fund Rating - Ji'an Jinxin Rating) and indicates the return type as Ji'an Jinxin Rating. It identifies the specific rating system and source, but lacks a strong verb and does not explicitly differentiate from sibling tools like fund_rating_sh or fund_rating_zs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description only covers the parameter and return type, without explaining when to choose this over other fund_rating_* tools or any context about the rating system.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds the data source (Eastmoney) and an example URL, plus the return type. However, it does not disclose what the table contains (e.g., columns, scope) or any behavioral nuances such as whether it is historical or static, which the tool name 'hist' suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no filler: a title, a source URL, and return-type annotations. Each element serves a purpose, though a sentence explaining the table's contents would improve it without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool, the description is incomplete. It does not explain what the returned table actually contains (e.g., columns, which exchanges, whether it is a static mapping or historical), nor does it mention the 'hist' aspect despite the tool name. Without an output schema, the vague return statement is insufficient for an agent to understand the result set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is trivially covered. The description adds the return type (pandas.DataFrame) and states the output is an exchange-variety comparison table, providing minimal but relevant information about the data shape. The baseline of 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description consists of the title, a sample URL, and a return-type line that essentially restates the title. There is no explicit verb indicating what the function does (e.g., fetch, get, retrieve). The core purpose is largely tautological: 'exchange-variety comparison table' repeats the tool's name and 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/5Does 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 the many futures-related alternatives, such as futures_hist_em or futures_contract_detail_em. It does not mention prerequisites, exclusions, or alternative tools, leaving the agent without selection 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds only a source URL and return type (pandas DataFrame), but no behavioral context such as data availability, pagination, rate limits, or error conditions. This is minimal additional value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the title and URL first, followed by parameter and return docstrings. It is efficient but slightly repetitive: the title is mentioned in the description, the annotations, and the return line. No unnecessary filler, but the redundancy prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not explain what columns or statistics the returned DataFrame contains. It also does not specify whether the date parameter is required, what happens with the default value, or whether the data covers a single day or a range. For a simple tool the description is still incomplete in explaining the actual output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for parameter meaning. It provides only '年月日' (year-month-day) for the date parameter, which is vague and does not explicitly clarify the format (e.g., YYYYMMDD). The default value hints at the format but is not a substitute for explicit guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving CZCE futures-to-spot statistics, with the exchange explicitly named, distinguishing it from sibling tools like futures_to_spot_dce and futures_to_spot_shfe. However, it is a noun phrase rather than a clear verb+resource statement, so it does not fully meet the highest bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that it is specific to CZCE, how it relates to other futures statistics tools, or any exclusions or prerequisites. The only hint is the exchange name in the title, which is not sufficient.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no behavioral context beyond that—no mention of data granularity, pagination, units, rate limits, or any side effects. The URL is a source link but does not disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fragmented: a bare title line, a URL, and a docstring-style parameter/return spec. There is no clear opening sentence that states the tool's function. While the length is short, the information is not structured or front-loaded, making it harder for an agent to quickly parse the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return value clearly. It only states '彭博亿万富豪指数历史数据' and 'pandas.DataFrame', but does not describe columns, row content, or the year range. It also omits whether the data reflects rankings, net worth figures, or other metrics. This leaves the tool's output ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for 'year', so the description adds value by indicating it is a choice of specific years ('2021', '2019', '2018', ...'). However, the list is incomplete and the ellipsis leaves ambiguity about valid values. The type (str) is also restated, but the allowed-value hint is useful. It does not fully compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and return type clearly indicate it returns historical Bloomberg Billionaires Index data ('彭博亿万富豪指数历史数据'). The description includes the source URL and parameter documentation, making the purpose evident. However, it lacks an explicit verb like 'retrieve' and does not differentiate from the sibling tool 'index_bloomberg_billionaires' (likely non-historical), so it is clear but not perfectly specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the sibling index_bloomberg_billionaires for current data, nor any other related tools. There is no context about typical use cases, prerequisites, or selection criteria.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds 'returns pandas.DataFrame' and a source URL, providing minor extra behavioral context (return format, source) without any contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a clear structure: title, URL, return annotation. Every line carries some information (source, return type), but it lacks a proper explanatory sentence, making it more under-specified than truly well-formatted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters or output schema, the description fails to explain what the returned DataFrame actually contains (columns, time range, frequency). It only repeats the name '财新中国 PMI-制造业 PMI', leaving the agent without enough context to know what data to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema (empty properties) fully covers parameter requirements per the baseline rule. The description does not need to elaborate on parameters; it appropriately omits them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name/title ('财新数据-指数报告-财新中国 PMI-制造业 PMI') without adding an explicit verb like 'get' or 'fetch'. It does provide a URL and return type, but the core purpose is a tautology of the title, offering no additional semantic clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling list includes other PMI-related tools (e.g., index_pmi_com_cx, index_pmi_ser_cx, macro_china_pmi) but the description does not differentiate this manufacturing PMI tool from them or suggest any selection criteria.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds only the source URL and return type, which are not behavioral traits such as rate limits, data update frequency, or potential errors. It provides minimal additional context beyond what annotations already offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but somewhat repetitive, echoing the title and using a docstring format. It includes the URL and return type, but the structure is flat and the information is thin. It is not overly long, but it under-specifies key details like data columns or units.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless data retrieval tool, the description should explain what the returned DataFrame contains (e.g., columns, units, date range). It only states the indicator name and return type, leaving the agent without enough information to understand the output or limitations. The absence of an output schema makes this gap more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is complete and the description does not need to explain parameter usage. The return type is mentioned but is not parameter-related. A baseline score of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the UK Rightmove house price index monthly rate from Eastmoney, including the source URL. It distinguishes from siblings like macro_uk_rightmove_yearly by specifying 'monthly' in the name and description. However, it lacks an explicit verb (e.g., 'fetch', 'get'), so the purpose is clear but not phrased as an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 that this is the monthly rate and that other tools exist for yearly rates or other UK economic indicators. No exclusions 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and return type but does not disclose additional behavior such as data volume, columns, or potential pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it consists of fragments rather than complete sentences and repeats the category 'T+0 QDII-亚洲市场-亚洲指数' twice. There is some redundancy, though it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what data the DataFrame contains, but it only gives a category name. The agent cannot infer the columns, row structure, or how to interpret the returned data, making the tool insufficiently specified for a simple data-listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'cookie' has no description in the schema, and the description does not mention it at all. With 0% schema coverage, the agent has no clue what the cookie parameter is for or when to provide it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (T+0 QDII-Asia Market-Asia Index) and its source (Jisilu URL), and states the return type (pandas.DataFrame). This clearly differentiates it from siblings like qdii_e_index_jsl and qdii_e_comm_jsl, though it lacks an explicit verb like 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios where other QDII 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame) but does not explain the optional 'cookie' parameter, rate limits, or any auth requirements beyond what the schema hints at.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of redundancy, but it is under-specified—it reads as a docstring stub with just a title, URL, and return type. It lacks narrative structure and is not appropriately sized for the information it should convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description gives the data source and return type but omits crucial details such as the actual content/structure of the DataFrame, the purpose of the cookie parameter, and any guidance on when to choose this among the many QDII-related siblings. An agent cannot assess suitability adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'cookie' with 0% description coverage, and the tool description does not mention the cookie parameter at all. The description provides no semantic information about when or how to supply a cookie, so the agent is left completely unguided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (Jisilu) and the specific category ('T+0 QDII-欧美市场-商品'), so the tool's purpose of returning commodity QDII data is fairly evident. However, it lacks an explicit verb such as 'fetches' or 'lists', and it does not differentiate among sibling QDII tools beyond the '商品' (commodity) hint in 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description only provides a title, URL, and return type; it fails to mention any specific use cases, prerequisites, or exclusions relative to similar QDII tools in the sibling list.
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?
The annotations already declare this as read-only, idempotent, and non-destructive, so the description's job is to add behavioral context. It adds a source URL and says the return type is pandas.DataFrame, but it does not describe the data range, columns, or whether it's a time series. The return description contradicts the title (PE vs PB), which is a misleading behavioral claim.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the :return: line is redundant and erroneous, repeating a data type that conflicts with the title. The URL is useful, but the overall structure is marred by the inconsistency, preventing a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input data retrieval tool, the description should clearly state what is returned. It fails to specify whether this is historical or current data, the exact columns, or the unit. The mistaken return type (PE instead of PB) further reduces completeness, as an agent would receive misleading information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, so the baseline for parameter semantics is 4. The description does not confuse parameter usage, and since there are none, there is little to add. However, the incorrect return type mention is a minor detractor, but it doesn't affect parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the tool's purpose: all A-share equal-weighted and median P/B ratios. However, the :return: line incorrectly states '市盈率' (P/E) instead of '市净率' (P/B), creating a contradiction that confuses the tool's actual output. The resource is clearly identified, but the inconsistency drops the clarity score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus other stock-valuation tools like stock_market_pb_lg or index_pe_lg. The intended use is only implied by the name and first line, but there are no explicit scenarios 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only that the return type is a pandas.DataFrame, which is useful but not behavioral context beyond what annotations imply. It does not mention data source quirks, possible failures for non-existent symbols, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes a reference URL and return type, which are potentially useful. However, the parameter section is essentially filler because it repeats the tool's purpose. The structure follows a docstring format and is front-loaded with the tool's name, but the content is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description is incomplete because it fails to explain the parameter semantics, which is the key piece of information needed to invoke the tool correctly. Annotations and the schema cover safety and the parameter's existence, but the meaning of 'symbol' remains ambiguous. The URL suggests a code format, but the default value is a name, creating confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter description is tautological: ':param symbol: 板块简介' repeats the same phrase used for the tool's purpose, and does not clarify what the symbol should represent (e.g., board name or code). The schema provides only a default value '半导体' (semiconductor) and no description. With schema description coverage at 0%, the description fails to compensate, leaving the agent uncertain whether to pass an industry name, a numeric code, or something else.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning an industry sector introduction from THS (同花顺), with a reference URL. It is clear from context that this is a data retrieval tool for sector overview information, and it distinguishes itself from sibling tools such as stock_board_industry_summary_ths and stock_board_industry_index_ths. However, it lacks an explicit verb like 'get' or 'return', making it a noun phrase rather than a full behavioral statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no exclusions, and no mention of when not to use it. Sibling tools cover similar THS industry board data (summary, name, index, constituents), but the description does not explain what differentiates this tool from them. The only hint is the title itself, which is insufficient for confident selection.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those. It adds the source URL and the fact that the return type is a pandas DataFrame. However, it discloses no additional behaviors such as rate limits, refresh frequency, or special fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the title and URL, but it is more of a header than an explanatory description. It is concise but lacks structured elaboration, and the return type is given in a docstring-like format rather than a natural sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool with no output schema, the description should clearly state what the resulting DataFrame contains. Merely saying 'MSCI' is ambiguous—does it return all MSCI ratings? For which companies? Any history? The source URL helps but does not replace a clear explanation of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so the description is not required to explain parameters. Baseline for zero-parameter tools is 4. The description does not contradict the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as Sina Finance ESG Rating Center's MSCI rating, but its purpose is stated via a title-like phrase rather than a clear verb-driven explanation. The name itself already conveys the same information, making the description only slightly more explanatory. It does specify the source and the return type, which adds a little clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 vs. alternative ESG tools. The description does not mention any context, prerequisites, or exclusions. Even with sibling tools like stock_esg_hz_sina or stock_esg_rate_sina, no differentiation is 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the description doesn't need to cover safety. However, it adds no behavioral context beyond 'returns a DataFrame'—it doesn't explain what the data contains, whether it's a complete snapshot, or any caveats about the data quality or refresh rate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it includes a full URL and a docstring-style return annotation. It is not poorly organized, yet the title is repeated verbatim and the URL is probably unnecessary for an agent. Still, it is efficient and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description is the only source of context. It fails to mention what columns the DataFrame contains, which companies are covered, whether it includes historical data, or any unique aspects of Sina's ESG ratings. This is barely more than a stub.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter ambiguity is nonexistent. The description adds no parameter details, but with no parameters, the baseline 4 is appropriate because there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns 'ESG评级数据' (ESG rating data) from Sina Finance, which is a clear data retrieval purpose. However, it does not specify the scope (e.g., all stocks, specific market) or distinguish it from sibling ESG tools like stock_esg_hz_sina, stock_esg_msci_sina, etc., making it generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the other ESG rating tools. The description merely names the data source and return type, with no mention of alternatives, prerequisites, or typical use cases.
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?
The annotations already indicate a safe read-only, idempotent operation. The description adds minimal behavioral context by specifying the return type (pandas.DataFrame) and the example URL, but does not disclose details about data coverage, potential failures, or any side effects beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but repeats the same Chinese title twice ('新浪财经-财务报表-关键指标') and includes a URL that, while informative, is not essential. The docstring-like structure is clear but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description only states that a pandas.DataFrame is returned. It does not specify what key indicators are included, the time period, or how it differs from similar financial analysis tools, leaving an agent under-informed for precise invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'symbol' is described as a stock code with a default value in the schema. The description adds minimal clarification by explicitly labeling it '股票代码' (stock code), but this is largely self-evident from the parameter name and default example in the URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns Sina Finance financial statement key indicators, with a URL and DataFrame return type. However, it lacks a clear verb (e.g., 'get' or 'fetch') and does not distinguish it from closely related sibling tools such as stock_financial_abstract_ths or stock_financial_analysis_indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many available alternatives. The description only documents the symbol parameter and return type, without mentioning appropriate contexts 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the return type (DataFrame) and a source URL, but does not disclose data scope, historical depth, or any other behavioral traits. It does not contradict the annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, structured docstring with a URL, parameter, and return section. It is not verbose and contains no filler. Some redundancy exists between the title in the annotations and the first line, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 is thin. It does not explain what columns the returned DataFrame contains, whether it returns historical or current holdings, or how it differs from the many sibling stock-connect tools. The URL hint is useful but insufficient for complete agent comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's parameter documentation (':param symbol: 股票代码', ':type symbol: str') provides essential meaning that the schema lacks. It clarifies that symbol is a stock code string, but does not specify format constraints, leading zeros, or the default behavior beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns '具体股票-沪深港通持股' (specific stock's Stock Connect holdings) and provides a URL example. It identifies the resource (a specific stock) and the data type (holdings). However, it does not explicitly distinguish itself from sibling tools like stock_hsgt_individual_detail_em or stock_hsgt_hold_stock_em, relying on the name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 is purely declarative, with no mention of use cases, prerequisites, or exclusions. Given the many related stock-connect tools in the sibling list, this is a significant gap.
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 already declare read-only, idempotent, and non-destructive behavior. The description adds the return type (pandas.DataFrame) and source URL, but it does not disclose additional behavioral traits such as date range limitations, data granularity, or response columns. No contradictions, but minimal added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title, a URL, and a brief docstring. It is front-loaded with the core purpose, and there is no wasteful prose. However, the docstring largely restates the title and parameters, and the URL could be considered extra.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains (columns, rows, and meaning). It only says '机构买卖每日统计' without specifying fields like stock code, buy amount, sell amount, or net buy. Given the numerous sibling LHB tools, this description is insufficient for an agent to predict the output or differentiate the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate, but it only repeats the parameter names and types ('start_date: 开始日期') without explaining format, inclusivity, or examples. The default values (20240430) implicitly suggest YYYYMMDD format, but this is not explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning Eastmoney's daily institutional buy/sell statistics from the Dragon Tiger List, which helps distinguish it from other LHB tools such as stock_lhb_detail_em or stock_lhb_jgstatistic_em. However, it lacks an explicit verb like 'fetch' or 'get', relying instead on a noun phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling LHB tools, nor any contextual or alternative recommendations. The description only provides parameters and a source URL, giving no indication of preferred use cases 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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, covering the safety profile. The description adds only the return type (pandas.DataFrame) and a repeated statement about margin transaction details, but no behavioral context such as date format expectations, error behavior, pagination, or rate limits. It does not contradict the annotations, but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring structure (title, param, return). It contains no unnecessary words. However, the first line largely repeats the tool name and the overall brevity leaves out important details, which is acceptable for conciseness but contributes to the completeness gap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and no output schema, so the description should clarify what the returned DataFrame contains. It only says '融资融券明细' (margin details), which is vague. It also omits the date format and any caveats about data availability. While annotations cover safety, the description is insufficient for an agent to fully understand the tool's output and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'date' parameter with 0% schema description coverage, so the description bears the full burden. It adds the meaning 'trading day' but does not specify the expected format (e.g., YYYYMMDD), provide examples, or explain how the date filters the returned data. This is minimal compensation for the lack of schema-level description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (Beijing Stock Exchange), the category (margin trading/securities lending), and the specific data (transaction details). However, it lacks an explicit verb like 'get' or 'retrieve' and does not distinguish itself from similar sibling tools (e.g., stock_margin_detail_sse, stock_margin_detail_szse) beyond the market name in the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or contrast with sibling tools such as stock_margin_bse or the SSE/SZSE margin detail tools. The only hint is the market name in the title, but that is not explicit usage guidance.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds the source URL and return type (pandas.DataFrame), which is useful but does not disclose additional behavioral traits like data freshness, frequency, or potential error conditions. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with a title line, URL, and return type. The URL and return type are valuable, but the title line is redundant with the tool name. It is concise and front-loaded, but the redundant title prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what data is returned. It only says '参考汇率' (reference exchange rate) and 'pandas.DataFrame', without specifying the currency pair, the date range, or the DataFrame columns. This ambiguity makes it hard for an agent to know what to expect, especially when choosing between SZSE and SSE variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameters to describe, and the description does not need to add parameter-level semantics. The schema coverage is 100% since there are no properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The main description line '深港通-港股通业务信息-参考汇率' is a noun phrase that restates the tool name in Chinese, with no action verb like 'get' or 'fetch'. The URL and :return: lines indicate the source and data type but still do not clearly state what the tool does. It fails to differentiate from the sibling stock_sgt_reference_exchange_rate_sse beyond the 'szse' in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the SSE counterpart or settlement exchange rate tools. The description lacks explicit context about SZSE-specific applicability or any exclusions, leaving the agent to infer usage solely from 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, covering the safety profile. The description adds only the source URL and return type, but no behavioral caveats, data scope, or performance characteristics. Minimal extra value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—a name, a URL, and return type—with no verbose filler. It is appropriately sized but borders on under-specification, lacking a structured explanation of what the classification entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only info tool, the description is sparse. It doesn't explain what fields or codes are included in the returned classification, nor how it differs from other Shenwan levels. Annotations cover safety, but the description misses important context about the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The baseline for no parameters is 4, and the description correctly notes the return type (pandas DataFrame). No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing Shenwan Level 2 industry classification, with a source URL and return type. This distinguishes it from siblings like sw_index_first_info and sw_index_third_info. However, it lacks an explicit verb, reading more as a label than a full description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 what it returns, with no mention of prerequisites, exclusions, or comparison with related Shenwan classification 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the source URL and return type but does not disclose behavioral details like pagination, data freshness, authentication needs, or how the 'symbol' parameter affects the result scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but structured as a docstring with a title, URL, and parameter/return sections. The purpose is not front-loaded as a concise sentence, and the URL and lengthy choice list add bulk without a clear functional summary. It is not overly verbose, but could be improved by adding a one-line operational description at the top.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the essentials: parameter choices, type, return type, and source URL. However, it doesn't specify the columns or contents of the returned DataFrame, and it lacks a clear behavioral overview, leaving the agent with an incomplete picture for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's 'symbol' property has no description (0% schema description coverage), so the description is the sole source of parameter semantics. It provides a comprehensive list of valid choices, the type (str), and the meaning (organization type), which is essential for correct invocation. However, it doesn't explain the default behavior when 'symbol' is omitted beyond what the schema default indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a Chinese title '基金从业人员资格注册信息' (fund practitioner qualification registration information) and then provides parameter/return docs, but it lacks an explicit verb phrase stating what operation is performed. The tool name contains 'list', implying retrieval of a list, but the description doesn't clearly say 'list fund practitioners by organization type' nor does it distinguish itself from the similar sibling amac_person_bond_org_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 conditions, prerequisites, exclusions, or name any sibling tools such as amac_person_bond_org_list, making it hard for an agent to decide between similar AMAC 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?
Annotations already declare read-only/idempotent behavior, so the bar is lower. The description adds context that the data is daily non-parametric measures, which helps interpret the output. However, it doesn't state behavior like invalid symbol handling or whether the 'short' version truncates data, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a long boilerplate paragraph about the Oxford-Man library, its research, and disclaimers that is not needed for tool invocation. Key info (param, return) appears early, but the essay-like content inflates the description unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema. The description explains what realized measures are conceptually but doesn't specify the DataFrame structure, date range, or what differentiates the 'short' version from the full version. This is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero description coverage, so the description compensates by listing valid symbol values (FTSE, GDAXI, RUT, SPX, STOXX50E, SSEC, N225) with index names. This is directly useful for parameter selection. The default is not mentioned, but the param explanation is solid for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Oxford-Man Realized Library) and states the return type, but lacks an explicit verb like 'retrieve' or 'get'. It also doesn't clarify what 'short' means relative to the sibling tool article_oman_rv, so the tool's specific function is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over article_oman_rv or article_rlab_rv. The long text describes the library's background but never mentions use cases, 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the return type (pandas.DataFrame) and source URL, but it does not mention behavioral traits like pagination, rate limits, or error handling. The added context is modest but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing a title, URL, and docstring. It is front-loaded with the purpose. However, the title duplicates the annotation title, and the URL may be extraneous for agent use, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, the description provides essential elements: data source, parameter meaning, and return type. It does not describe the contents of the adjustment records or any caveats, but it is mostly adequate for basic selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It says ':param symbol: 可转债代码', which conveys that symbol is the convertible bond code. This is minimal and does not explain format, examples, or how to find valid codes beyond the schema default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (可转债转股价调整记录) and indicates it returns a pandas.DataFrame, but it lacks an explicit action verb like 'get' or 'fetch'. It reads as a label rather than a clear function. It is distinguishable from siblings like bond_cb_redeem_jsl by focusing on adjustment logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 includes a data source URL but no exclusions or comparisons with sibling tools like bond_cb_jsl. The only implicit context is that it is for adjustment records.
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?
The annotations already declare the tool as read-only, idempotent, and non-destructive, covering the safety profile. The description adds a critical behavioral detail: it requires a browser cookie for invocation, which is not captured by the annotations. This is significant context for the agent, though it does not explain why the cookie is needed or what happens if it is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes the URL, parameter, and return type, but it is formatted as a docstring with tags rather than a clear natural-language explanation. It is not bloated, but it lacks a clear imperative statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and clear annotations, the description covers the basic invocation details. However, it does not describe the contents of the returned DataFrame, any authentication nuances, or how the tool behaves with or without the cookie, which could leave the agent uncertain about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides the only semantic meaning for the cookie parameter, stating it is a browser cookie to input. This is helpful, but it omits details such as whether the cookie is optional, its format, or how to obtain it, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description simply repeats the tool's name ('集思录可转债') and provides a URL, without any action verb or explicit statement of what the tool does. It does not differentiate from sibling tools like bond_cb_index_jsl or bond_cb_adj_logs_jsl, leaving the agent to infer its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites beyond the cookie parameter. It only states the resource source, making it difficult for an agent to decide among the many bond-related 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds a source URL and states the return type as pandas.DataFrame, which is useful but minimal. It does not disclose data freshness, pagination, or any site-specific quirks. Without annotations, this would be insufficient, but annotations carry the core safety burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a breadcrumb, a URL, and a short docstring. It front-loads the purpose and includes a source link. However, the structure is slightly awkward, mixing a human-readable heading with code-style docstring, and the copy-paste error in the end_date description detracts from clarity. It is not verbose, but not well-polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should describe the returned data structure, but it only says '企业债发行' as a generic return label. It also omits date format details, allowed ranges, timezone considerations, or any limitations of the data source. Given the tool has just two parameters and a simple return, the description leaves the agent with insufficient information for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It attempts to do so with ':param start_date: 开始统计时间' and ':param end_date: 开始统计时间', but both are described as the 'start time', which is clearly an error for end_date. This misleads the agent about the semantics of end_date. Even the start_date description is vague ('统计时间' could mean many things), and no date format constraints beyond the defaults are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '巨潮资讯-数据中心-专题统计-债券报表-债券发行-企业债发行' (Cninfo Data Center - Bond Reports - Bond Issuance - Corporate Bond Issuance). Although it lacks an explicit verb like 'fetch' or 'retrieve', the combination of the breadcrumb and return type makes it evident this returns corporate bond issuance data. It distinguishes itself from sibling bond issuance tools (e.g., bond_cov_issue_cninfo, bond_local_government_issue_cninfo) via the specific '企业债发行' subcategory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or exclusions. The only contextual hint is the breadcrumb, which implies it is for corporate bond issuance, but there is no explicit 'when to use this, use X for other bond types' guidance.
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?
The description includes the source URL and return type, which offers some context about data origin, but it does not disclose any behavioral traits like data freshness, pagination, or potential network dependencies. The annotations already declare read-only and non-destructive behavior, so the description adds little beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains only a source URL and return type, which is efficient but lacks structural prose. It is not bloated, though it is under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify what the returned DataFrame contains. It merely repeats '现券市场做市报价' (spot market-making quotes), which adds little beyond the tool name, leaving the row/column structure and data scope unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, and the input schema is empty with 100% coverage. The description does not need to explain parameter semantics, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing spot market-making quotes from China Money, but it does so in a fragmentary way with no explicit verb. It restates the tool name with minimal elaboration, making it hard to distinguish from sibling bond spot tools without deeper inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 similar bond quote tools. There are no exclusions, alternatives, or context cues beyond the source URL.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds some context by specifying the return type as pandas.Series and linking to external API docs, but it does not disclose other behavioral traits like data freshness, rate limits, or failure modes. Overall, it provides modest additional value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a title line, API documentation link, and structured parameter/return sections. It is not overly verbose, but the opening line 'currencies data from currencyscoop.com' is more of a title than a functional description, and the link could be integrated more efficiently. Overall, the structure is clear and reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain return values, but it only says 'Latest data of base currency' with rtype pandas.Series, which is vague and does not clarify the conversion result. It also misses critical context like error handling, API key requirement implications, and the exact meaning of the returned data in relation to conversion. The description is incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the param documentation burden, and it does provide descriptions for all four parameters (base, to, amount, api_key). However, the descriptions are ambiguous (e.g., 'The currency you would like to use for your rates' for 'to') and do not specify currency code formats or clarify that amount should be a numeric string. It partially compensates for the schema gap but leaves room for misinterpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'currency_convert' and parameters (base, to, amount) suggest currency conversion, but the description only says 'currencies data from currencyscoop.com' without a clear verb or outcome. It fails to explicitly state that it converts an amount from one currency to another, leaving the exact purpose somewhat implied and not fully differentiated from sibling tools like currency_latest or currency_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 currency_latest, currency_history, or forex_spot_em. The description lacks any context about typical use cases, prerequisites (e.g., API key), or exclusions, leaving the agent without direction on tool selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that the data comes from Sina Finance and returns a pandas.DataFrame, plus a reference URL. However, it does not disclose any behavioral details such as data frequency, pagination, or limitations. Given the annotations cover the safety profile, adding the source and return type provides marginal extra value, but not enough to score higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short, but its structure is a jumble: a title line, an unformatted URL, and a docstring-style param/return block. It lacks a clear opening sentence with a verb. The URL is arguably redundant for an agent. While no part is wastefully verbose, the lack of coherent structure and front-loading prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining the return value. It only says '累计分红' (cumulative dividends) and 'pandas.DataFrame', which essentially repeats the title. It does not describe the columns, the meaning of 'cumulative', or whether the data covers the full dividend history. For an agent to confidently use the tool, more detail is needed, so this is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'symbol' with no description, so schema coverage is 0%. The description attempts to explain it as '基金名称' (fund name) and says it can be obtained via ak.fund_etf_category_sina(). This is partially helpful for finding valid values, but 'fund name' is misleading; the default 'sh510050' is an exchange symbol, not a name. The description does not fully clarify the expected format (e.g., prefix 'sh'/'sz'), leaving the agent with an inaccurate mental model.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with '新浪财经-基金-ETF 基金-累计分红' which clearly identifies the resource as cumulative dividends for ETF funds from Sina Finance. Although it is a title rather than a full sentence with a verb, the intent is unambiguous and distinguishes this tool from sibling tools like fund_etf_hist_sina (historical prices) and fund_etf_spot_em (spot quotes). The URL and return type further reinforce the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It only mentions how to obtain the symbol via ak.fund_etf_category_sina() as a prerequisite, but does not explain when to choose this dividend tool over other fund-related tools (e.g., fund_announcement_dividend_em). There are no exclusions or comparisons to siblings, leaving the agent to infer usage from the name and title.
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 already declare readOnlyHint, idempotentHint, and destructiveHint:false, so the safety profile is covered. However, the description adds no extra behavioral context beyond this, such as rate limits, error behavior, or what happens with invalid fund codes. The example URL and parameter docs do not disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, example URL, parameter documentation, and return type. It is structured and not verbose, making it easy to scan. The example URL provides a concrete endpoint reference without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only fund performance query, the description adequately covers parameter semantics and return type. However, it does not describe the contents of the returned DataFrame (e.g., columns, metrics) or provide usage context, leaving some gaps for a complete understanding. The annotations handle safety, so completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, so the description compensates by defining 'symbol' as the fund code and 'timeout' as a choice of None or a positive float. This adds semantic meaning beyond the raw types, but it is minimal and does not explain the expected format of the fund code or provide examples beyond the schema's default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool returns fund performance (基金业绩) for a given fund code, with a return type of pandas.DataFrame. It distinguishes from sibling tools that focus on analysis, basic info, or holdings by specifying 'achievement' (业绩), though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 such as fund_individual_analysis_xq or fund_individual_basic_info_xq. The description only documents parameters and return type, with no mention of use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the return type and source URL but no behavioral nuances such as data scope, freshness, or required authentication. It does not contradict the annotations, but it offers no additional behavioral context beyond what the annotations supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief: one title line, a URL, and two return tags. It is front-loaded and each line serves a purpose. The URL is somewhat long but adds source specificity. It avoids unnecessary verbosity, making it a concise representation for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining the return value. It only states '基金规模' and 'pandas.DataFrame', leaving the structure and content of the DataFrame undefined (e.g., fund codes, names, scale amounts, or time range). For a zero-parameter tool, this lack of detail limits the agent's ability to interpret and use the returned data effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, giving a schema description coverage of 100%. With no parameters to document, the description needs no parameter details, and the baseline for 0 params is 4. The description does not mislead or introduce any parameter-related confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a Chinese title '新浪财经-基金数据中心-基金规模-分级子基金' and a URL, indicating it retrieves fund-scale data for graded sub-funds from Sina Finance. It does not include an explicit action verb like 'get' or 'retrieve', making the purpose clear but not strongly purposeful. It does distinguish from sibling tools such as fund_scale_close_sina and fund_scale_open_sina by specifying '分级子基金'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention any exclusions, prerequisites, or alternative tools, even though siblings like fund_scale_close_sina and fund_scale_open_sina exist. The URL merely points to the data source but provides no contextual usage instructions.
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 already cover the safety profile (readOnlyHint=true, destructiveHint=false). The description adds a return type (pandas.DataFrame) and a reference URL but does not disclose additional behavioral traits such as error handling, data coverage, or limitations. Given the annotation coverage, it provides minimal but non-redundant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but mixes Chinese text, a URL, and docstring-style lines without a clear front-loaded summary. It is under-specified rather than concise, and the structure is not optimized for quick agent scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what '期货合约详情' includes, but it only mentions 'pandas.DataFrame' without specifying fields or content. Combined with many similar futures tools, the lack of detail leaves the agent uncertain about what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It says 'symbol: 合约' (contract) and type str, with 'v2602F' shown in the URL as an example. This is minimal and does not clarify the expected symbol format, possible exchange conventions, or how the agent should construct a valid symbol.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states '查询期货合约详情' (query futures contract details), which clearly identifies the operation and resource. However, it does not explain how this tool differs from the nearly identical sibling 'futures_contract_detail' or what the '_em' suffix denotes, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the many similar futures tools. The description includes a URL and parameter documentation but does not mention preferred contexts, exclusions, or alternatives, leaving tool selection ambiguous.
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 already declare readOnlyHint, openWorldHint, and idempotentHint true, so the safety profile is established. The description adds the data availability range and shows the output format via sample data, but doesn't disclose additional behavioral traits such as pagination, error handling, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated by a large sample DataFrame extending dozens of rows, which consumes most of the text. Essential information like the availability range and param meanings is buried at the top, but the sample output overwhelms. This is not concise nor well-structured for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the sample data compensates by showing the columns (name, value, ratio, date) and the return type (pandas.DataFrame). The data range is stated, and defaults are in schema. However, the misleading param description and lack of error handling info leave some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate, but it fails. The param documentation labels date as "中文名称" (Chinese name), which is misleading, and doesn't clarify the expected date format (YYYYMMDD vs YYYY-MM-DD). The availability range is provided but not explicitly linked to the date parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving turnover distribution ("成交额分布") from the Qihuo Kechai data source, and specifies the available date range. It distinguishes from sibling tools like get_qhkc_fund_bs and get_qhkc_fund_position by focusing on transaction amount distribution, though it doesn't 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 Guidelines2/5Does 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 the data availability range and parameters, with no mention of exclusions or preferred contexts. The agent is left to infer usage from the name.
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 already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL (https://yun.ccxe.com.cn/indices/nei) and the return type (pandas.DataFrame), which is some useful context. However, it does not disclose other behavioral aspects like data freshness, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but is under-specified rather than concise. It is essentially a title, a URL, and a return line with no structured explanation or front-loaded purpose. The content feels incomplete and does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description is the only source of semantics. It merely states the returns a '大宗商品指数' with a URL, but fails to specify what this index covers, its frequency, units, or how it differs from sibling index tools. This is insufficient for an agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema fully documents the absence of inputs. The description adds the return type and the fact that it returns a commodity index, which provides a bit of semantic context. With 0 params, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description mainly restates the title (财新数据-指数报告-大宗商品指数) and adds a return line (':return: 大宗商品指数'). It conveys that the tool returns a commodity index, but without a clear verb or explicit action, the purpose remains vague. It does not distinguish this tool from many sibling index_* 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool vs alternatives. The description lacks any context, scenarios, or exclusions, leaving the agent without information on how to select this tool among the many similar index_* functions.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that it returns a pandas.DataFrame and provides a source URL, but it does not disclose any potential behavioral traits such as data delay, column structure, or error conditions. It barely goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is not inherently bad, but it is somewhat unstructured—it reads as a title followed by a URL and return type. It is concise but not optimally organized, and it under-specifies the content of the returned DataFrame. It avoids unnecessary words, but the brevity borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool, this description is minimally viable. It identifies the data source and return type, but does not describe what the DataFrame contains (e.g., columns, time range, or units). Since there is no output schema, the description should have provided more context about the actual data, but the simplicity of the tool and strong annotations partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information to add, and the description does not need to explain anything. The schema coverage is effectively complete, and the description adds no conflicting or missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '财新数据-指数报告-高质量因子' (Caixin Data - Index Report - High Quality Factor) and states it returns a DataFrame of '高质量因子'. This gives a specific resource and data type, but lacks a clear verb and does not distinguish it from sibling tools like index_ai_cx or index_si_cx. The URL provides a source, but the purpose is more of a label than a full explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description only states the data source and return type; it does not mention exclusions, prerequisites, or context where other tools would be more appropriate. With no parameters, usage is trivial, but the description still fails to explain when to call it.
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 already declare readOnly, idempotent, and non-destructive hints. The description adds a pandas.DataFrame return type and a source URL but no additional behavioral context such as date range, units, frequency, or potential quirks. There is no contradiction with annotations, but the added value 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, front-loaded with the title, then source URL and return type. It is concise with minimal repetition, though the URL may be of limited value for an AI agent deciding to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains. It only states 'GDP月率' (GDP monthly rate), which is vague and lacks details on columns, units, historical depth, or the exact metric (e.g., month-over-month growth rate). An agent would have to inspect the data to understand its structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully complete. Per the rubric, a 0-parameter tool receives a baseline of 4; the description does not need to add parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Canada GDP monthly rate) via the Chinese title and return line, but it lacks an explicit verb and is essentially a restatement of the tool name. It does not differentiate from closely related sibling tools like macro_canada_cpi_monthly or macro_canada_bank_rate beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only includes a source URL and return type, with no mention of preferred use cases, exclusions, or comparison to other macro indicators.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds only a URL and return type, contributing no additional behavioral context such as data scope, update frequency, or access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the name, but it repeats '农副指数' multiple times and compresses information into a docstring format. It is minimally sufficient but not well-structured or informative enough to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description provides the essential idea (returns agricultural index data) and a source URL. However, it lacks details about the data content, time range, or intended use, leaving room for confusion about what exactly is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%. The baseline for zero-parameter tools is 4; the description does not need to explain parameters. The lack of parameter information is not a gap because there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('农副指数' / agricultural by-product index) and specifies the return type as pandas.DataFrame, indicating it retrieves index data. However, it lacks an explicit verb (e.g., 'get' or 'fetch') and does not differentiate from siblings like macro_china_energy_index beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No context is given about the type of data, its source, or how it differs from related macro_china_* tools. The agent is left to infer usage from the name and URL.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds only the return type (pandas.DataFrame) and a source URL, but does not disclose any behavioral traits such as data granularity, network dependence, or potential delays. With no output schema, the description carries the burden of explaining what the agent can expect, and it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and does not waste words, but it mixes a Chinese term, a URL, and Python docstring conventions in a somewhat unstructured way. It is front-loaded with the indicator name, which is helpful. It earns a 4 for being brief, though it could be more coherent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter read-only tool, but the description lacks essential context about the data: what columns the DataFrame contains, whether it covers large/small financial institutions, historical depth, or update frequency. Since there is no output schema, the description should explain the return data's structure and scope, but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 schema coverage is trivially 100% with no properties, and the description does not need to elaborate on inputs. No additional parameter meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (存款准备金率 - deposit reserve ratio) and states it returns a pandas DataFrame, but lacks an explicit verb (e.g., 'get', 'fetch') or scope (e.g., historical, current). It does not distinguish itself from other macro_china_* sibling tools beyond the name itself, making the purpose somewhat vague but still inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_china_money_supply or macro_china_pmi. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without context for selecting this 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the return type (pandas.DataFrame) and source URL, which is some context, but it does not disclose any additional behavioral traits such as data range, freshness, or units. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three lines and compact, containing the title, source URL, and return type. It is not verbose and each line carries some information, though it is more of a metadata listing than a coherent prose description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain the returned data. It minimally states that the return is the IFO index as a DataFrame, but lacks specifics about columns, frequency, or units. This is adequate for a simple zero-parameter fetch but leaves ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to document parameters and it does not, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a title and a URL, with a docstring-like :return: line. It restates the tool name 'macro_germany_ifo' as '德国-IFO商业景气指数' without an active verb or a clear explanatory sentence, making it closer to a tautology. It adds the source URL and return type, but the core purpose is simply a label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling macro tools (e.g., macro_germany_cpi, macro_germany_gdp). It only provides a source URL and return type, so the agent gets no decision support or alternative 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?
While annotations already indicate a safe read operation (readOnlyHint=true, destructiveHint=false), the description adds a date range and source URL, but it also states a wrong return type (EIA crude oil inventory). This is actively misleading about the tool's behavior and output, failing to provide accurate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it includes an erroneous return line that contradicts the tool's purpose. The URL and date range are useful, but the misleading return information wastes space and harms clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple annotations, the description should clarify what the returned DataFrame contains. It fails to do so and instead gives an incorrect return description. The data range and source are helpful, but the completeness is undermined by the wrong return type and lack of column/unit details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain beyond the schema. The baseline for 0 parameters is 4, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the US initial jobless claims report (美国初请失业金人数报告) with a specific date range, distinguishing it from other macro_usa_* tools. However, the return line incorrectly mentions the EIA crude oil inventory report, which introduces confusion about the actual deliverable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 context, prerequisites, or exclusions, and with many similar macroeconomic tools available, the agent is left without direction.
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 already disclose read-only, open-world, idempotent, and non-destructive behavior. The description adds the source URL and return type (pandas.DataFrame), but does not elaborate on data freshness, coverage, or any special behavior. This is sufficient given the strong annotation coverage, matching a baseline of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—one title line, one URL, and one return line. It is concise without redundant prose. The title line repeats the annotations but adds the URL and return type, making it compact and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with rich annotations, the description gives a minimal but usable summary: source (East Money), return type (DataFrame), and content (option prices). However, it lacks details on what exactly constitutes 'current' (e.g., real-time snapshot, all contracts) and may not fully prepare the agent to interpret the result or choose among the many option tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms no properties. With no parameters to describe, the baseline of 4 applies. The description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a noun phrase ('东方财富网-行情中心-期权市场') identical to the title, providing no explicit verb or action. The return line '期权价格' hints at output but does not clearly state what the tool does (e.g., 'get current option prices from East Money'). It does not distinguish itself from numerous sibling option tools like option_sse_daily_sina or option_current_day_sse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No mention of whether it suits current market overview, real-time quotes, or specific underlyings. Sibling tools cover many option scenarios, but no comparative context is 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a source URL and return type (pandas.DataFrame) but no further behavioral details such as data frequency, pagination, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and not overly verbose, but it is structured like a docstring with a URL and parameter stubs rather than a concise agent-facing summary. It repeats the title without providing a clearer action statement, yet it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description fails to explain the output columns, symbol format, data frequency, or what the DataFrame contains. While annotations cover safety, the missing operational details leave the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's parameter docs are minimal translations ('start time', 'end time', 'index data') that add little beyond the schema's property names and defaults. The symbol parameter format is ambiguous (e.g., code vs. name) and the example URL uses a code while the default is a name, creating confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource (同花顺行业板块指数数据) and includes a URL and return type, indicating it retrieves industry index data. However, it lacks an explicit action verb and does not differentiate from sibling tools like stock_board_industry_info_ths or stock_board_industry_hist_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No context about preferred use cases, alternatives, or exclusions is provided, leaving the agent without direction on tool selection.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety behavior is covered. The description adds the source URL and a pandas DataFrame return type, but gives no further details on what the indicator output contains, date-range behavior, or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with a source URL, labeled parameters, and return type. It contains a redundant repeat of the title in the return line, but the overall size is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description only says the result is a DataFrame of 'financial indicators' without listing fields, period granularity, or any caveats. The two-parameter surface is simple, but the missing output details and absent sibling differentiation make it incomplete for confident selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the docstring's 'symbol: 股票代码' and 'start_year: 开始年份' provide basic meaning beyond the bare property names. However, they are minimal translations and do not explain value formats, the default 1900 semantics, or how start_year bounds the returned periods.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the same noun phrase as the title—'新浪财经-财务分析-财务指标'—and adds a URL, but it never states an action like 'fetches' or 'queries'. The resource and source are identifiable, yet the lack of a verb and no explicit comparison to the similar sibling 'stock_financial_analysis_indicator_em' leaves the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no 'when to use this vs alternatives' guidance. The description only lists parameters and a return type; it does not say when this Sina-based indicator tool should be preferred over siblings like stock_financial_analysis_indicator_em or stock_financial_abstract.
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 already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is known. However, the description adds minimal behavioral context—it only states the return type as pandas.DataFrame and does not disclose potential limitations, rate limits, data scope details, or any quirks. This adds little value beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a standard docstring with title, URL, parameter docs, and return type. It is reasonably sized but contains redundancy: the title '东方财富-A股-财务分析-主要指标' appears in the first line and again in the return line. The URL is verbose and may not be necessary for function invocation. Overall, it is functional but not tightly written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read-only tool, the description provides decent parameter semantics and return type. However, it does not enumerate which specific financial indicators are included, nor does it clarify whether the data is historical or current, or how it differs from similar tools like stock_financial_analysis_indicator. The absence of an output schema increases the need for such detail, leaving the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), but the description compensates by documenting both parameters: symbol is explained as '股票代码（带市场标识）' (stock code with market identifier) with a default example '301389.SZ', and indicator is given a choice of '按报告期' or '按单季度'. This adds clear meaning beyond the bare schema, making the parameters understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '东方财富-A股-财务分析-主要指标', which is essentially the same as the tool's title/name, providing no active verb like 'retrieve' or 'list'. It states the resource (Eastmoney A-share financial main indicators) but does not clearly articulate the action or scope, making it vague rather than a specific verb+resource+scope statement. The URL and return type add some context, but the core purpose is implied rather than explicitly described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_financial_analysis_indicator or stock_financial_abstract. The description only provides parameter explanations and does not state appropriate contexts, prerequisites, or when not to use the tool. Sibling differentiation is absent.
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 already indicate read-only and idempotent. The description adds that it returns real-time quotes as a DataFrame, but it also introduces an inconsistency by calling the output US stocks. No other behavioral details (e.g., data freshness, column meanings) are disclosed. This is not an annotation contradiction, but it reduces trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, includes a source URL and return type, but the mislabeling of output as US stocks makes it poorly structured and confusing. The 'return' line is clearly erroneous, so the conciseness is undermined by incorrect information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description provides the source and data type, but fails to specify what columns/fields are included or clarify the market (it says HK in the heading but US in the return). Given the availability of sibling tools, it needs better differentiation and accuracy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, and the schema is empty (100% coverage by default). Since there are no parameters to document, the description does not need to add parameter detail; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source and market (港股市场, 知名港股), but the return description mislabels the result as '知名美股实时行情', conflicting with the tool's name and source URL. The core purpose is still discernible but the error undermines clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs sibling tools like stock_hk_spot, stock_hk_main_board_spot_em, or stock_us_famous_spot_em. The URL and market name imply it's for well-known HK stocks, but no exclusions or alternatives 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the return type is a pandas.DataFrame, but provides no additional behavioral context such as data range, columns, or source-specific quirks. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a title line, a source URL, and short docstring entries for the parameter and return value. It is reasonably well-structured for a simple tool, though the first line is redundant with the title annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and limited parameter metadata, the description should clarify what the returned '指数数据' actually contains—e.g., daily OHLC, date range, or columns. It only gives the generic phrase '指数数据' and a URL, leaving the output structure ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by defining symbol as '港股指数代码' (HK stock index code) and pointing to a function for obtaining valid codes. However, it lacks concrete examples, format details, or an explanation of what the default value (HSTECF2L) represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '港股-股票指数数据' (HK stock index data) and states it returns '指数数据' (index data), but it lacks an explicit verb like '获取' (fetch) and does not mention that this provides daily historical data—its key differentiator from the spot-data sibling. The main distinguishing feature is only implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_hk_index_daily_sina or stock_hk_index_spot_em. The only hint, '可以通过 ak.stock_hk_index_spot_em() 获取' (can be obtained via ak.stock_hk_index_spot_em()), addresses how to find the symbol parameter, not which tool to select.
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 already indicate read-only, idempotent, and non-destructive behavior. The description adds little beyond a source URL and return type; it does not disclose what data is included, whether it is historical or current, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a clear docstring structure with source, parameter, and return sections. It front-loads the source and purpose, with no redundant or verbose content, though it is under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description needed to explain what '上市相关' includes, but it only returns a vague label. It does not specify the data fields, time range, or any distinctions from similar IPO tools, leaving the agent uncertain about the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a default value for symbol with 0% description coverage. The description compensates by explicitly documenting 'symbol: 股票代码' (stock code) and its string type, giving the agent the key meaning needed to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides '巨潮资讯-个股-上市相关' (CNInfo individual stock listing-related) and returns a pandas DataFrame, but it lacks an explicit verb and the scope '上市相关' is broad. The tool name hints at IPO summary, but the description alone does not clearly distinguish it from sibling stock_ipo_* 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/5Does 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. The many sibling IPO tools (e.g., stock_ipo_info, stock_new_ipo_cninfo) are not mentioned, nor are any prerequisites 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?
Annotations declare readOnlyHint=true and destructiveHint=false, which already establish safe read behavior. The description adds the data source URL and return type, but does not disclose rate limits, pagination, data freshness, or any caveats about the returned disclosure data. It does not contradict annotations; it simply provides minimal extra 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a consistent docstring structure. The title, URL, and parameters are listed with little waste, though the duplicated '开始时间' for end_date is a clear error that should be fixed. It is not front-loaded with a single-sentence summary, but it remains relatively efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, but it only states that the result is a DataFrame for the given symbol. It does not explain what the scheduled disclosure ('预约披露') data contains, what columns are returned, or how the date range interacts with the survey. An agent cannot tell if this is the correct tool for a specific disclosure relationship query without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions, so the docstring's param blocks are the only source of meaning. It defines symbol as stock code, market with an explicit choice set, and dates as start/end time. However, end_date is incorrectly described as '开始时间' (start time) instead of '结束时间', and the date format is only inferable from defaults. This partial but flawed documentation earns a mid score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a source title and URL but never states the tool's action. The return type is specified as pandas.DataFrame for the given symbol, but the data content is only implied by the title '预约披露调研'. No explicit verb like 'query' or 'list', and no differentiation from sibling tools such as stock_zh_a_disclosure_report_cninfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusion conditions. The only contextual hint is the URL, which does not help an agent choose among the many cninfo-related functions.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds no behavioral details beyond a source URL, such as rate limits, data update frequency, or dependencies. The URL provides provenance but not operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a title, URL, and docstring, and is front-loaded with the title. The URL line is not well integrated into the description, and the docstring is presented in a standard but somewhat mechanical format. It is concise but could be more readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema. The description covers the purpose, the parameter's meaning, and the return type (pandas.DataFrame) via the docstring. It misses market-specific details (e.g., Shanghai vs. Shenzhen) and does not mention any filtering options or data scope, but it is adequate for a basic historical data fetcher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the meaning '质押式回购代码' (pledged repo code) to the symbol parameter, which is useful since the schema only provides type and default. However, it does not elaborate on valid code formats, examples beyond the default, or how the code maps to a specific market.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing historical pledged repo data from East Money, using the term '历史数据' (historical data) and a source URL. It specifies the resource type (质押式回购) and distinguishes from other bond tools by focusing on historical data. However, it lacks an explicit verb phrase like 'fetches' or 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as bond_sh_buy_back_em or bond_sz_buy_back_em. There is no mention of exclusions, prerequisites, or specific use cases beyond the generic historical data context.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds the source URL and return type, but does not disclose any further behavioral traits such as data granularity, date range limitations, or potential missing data. It adds some value beyond annotations but is 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and follows a structured docstring format with URL, param, and return sections. Every line serves a purpose, and there is no fluff. It could be improved by leading with an explicit action verb, but it is efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 still thin. It does not describe what columns or content the returned DataFrame contains, nor the date format or any specifics about the bond turnover overview. The source URL is helpful, but an AI agent would need more detail to correctly interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It only provides a minimal '指定日期' (specified date) and type str, with a default example '20210104'. It does not explicitly explain the date format (YYYYMMDD) or whether the parameter is optional beyond the default. The compensation is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource clearly: SSE bond market turnover overview, with a source URL. Although it lacks an explicit verb like 'retrieve' or 'fetch', the docstring format and return type imply data retrieval. It partially distinguishes from siblings via the tool name 'deal_summary' vs 'cash_summary', but the description itself doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 context in which the tool is appropriate. The only hint is the date parameter, but there is no explanation of typical usage scenarios.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds a return type (pandas.DataFrame) and an example URL, but does not disclose output columns, pair direction semantics, or potential edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and uses a clear docstring structure with param/type/return/rtype sections. It has no redundant filler, but it is so terse that it omits important usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a sparse description, the return structure and symbol format are under-specified. The example URL uses currency codes (cny-jmd) while the default symbol is a Chinese name ('美元'), creating ambiguity about what the agent should pass.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter, but it only repeats 'specified currency' and the type str, adding little beyond the parameter name. It does not specify whether the value should be a currency code like 'USD', a Chinese name like '美元', or how to discover valid symbols.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource: 'all obtainable currency pair data for a specified currency', which clearly conveys what the tool returns. It does not explicitly differentiate itself from sibling currency tools like currency_latest or currency_convert, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many related currency/forex siblings. The description only says what it returns, with no mention of prerequisites, alternatives, or typical use cases.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'need special authority' and API key requirement, which is useful. However, the return docstring 'Latest data of base currency' is misleading for a time-series tool, and there is no disclosure of rate limits, error behavior, or date range constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short purpose line followed by a standard docstring block. It is structured and readable, but not front-loaded: the critical 'need special authority' note is buried in the second line, and the param docs could be condensed into a more concise narrative. The external link adds value but the overall length is somewhat excessive for an MCP tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains (columns, index, etc.), but it only says 'Latest data of base currency' which is inaccurate for a time series. It also does not clarify the interplay of start_date, end_date, and symbols, or what happens when all parameters are optional with defaults. The external API documentation link helps but does not compensate for the missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden for parameter meaning. It documents all five parameters with types, date examples for start_date and end_date, clarifies symbols is a list, and gives specific guidance for api_key. Minor vagueness remains: the symbols description says 'You can refer to a list all supported currencies here' without a working link, but overall it compensates well for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Time-series data from currencyscoop.com' which identifies the resource and data type but lacks an explicit verb like 'retrieve' or 'fetch'. The parameter and return docs make the function's purpose clearer, and it is distinguishable from sibling currency tools like currency_latest because it focuses on time series over a date range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like currency_history, currency_latest, or currency_convert. The only contextual note is 'need special authority', which is a warning rather than a usage guideline. No explicit exclusions or recommended scenarios 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the valid date range 'from "2015-01" to now' and the return type (pandas.DataFrame), which is useful context beyond the annotations. However, it does not disclose any additional behavioral traits like pagination, data limitations, or error handling, and the 'Comments or suggestions are welcome' line is irrelevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is padded with irrelevant content such as 'Comments or suggestions are welcome' and a verbose citation. The key parameter and return information appears only at the end, making the structure less front-loaded. Several sentences earn no functional value for an AI agent selecting or invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 is adequate but not complete. It identifies the dataset, the date parameter's format and range, and the return type. However, it leaves ambiguity about what the returned DataFrame contains (columns, multiple series) and whether 'date' refers to a single quarter or a range. Given the lack of output schema, more detail on the return shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'date' as a string with a default and no description (0% coverage). The description compensates by providing a concrete example ('2020-03') and the valid range ('from "2015-01" to now'), which clarifies the expected format and bounds. This is valuable, though it does not fully explain the semantic role of the date (e.g., specific quarter vs. start of a range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies FRED-QD as a quarterly frequency companion to FRED-MD, which distinguishes it from fred_md and other macro tools. However, it lacks an explicit action verb such as 'fetch' or 'retrieve'—the tool's purpose is implied rather than stated. The resource and scope are present, but the verb is missing, making it less clear than a strong action-oriented 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The phrase 'quarterly frequency companion to FRED-MD' hints at a use case (quarterly vs. monthly data), but no direct instruction or exclusion is provided. No prerequisites, alternatives, or context for choosing this tool over siblings like fred_md are mentioned.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the source URL and the fact that it returns a DataFrame. It does not disclose any additional behavioral traits such as data freshness, update frequency, size limits, or whether it includes historical data or only current shares. The minimal addition leaves the agent without useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three lines) and includes the title, a URL, and return type. It is concise, but the structure is raw and resembles a docstring fragment. The URL and return type are relevant, but the overall formatting is not polished. It earns a mid score because it is not verbose but also not well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description should clearly explain what data is returned, how current it is, and how it relates to other tools. The description merely states 'ETF基金份额数据' (ETF fund shares data) and the DataFrame return type. It does not mention the time span, columns, or whether it is a snapshot or time series. Also, it fails to differentiate from similar SZSE scale tools like fund_scale_daily_szse, making it incomplete for an agent to select correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 doesn't need to explain parameters, and the schema confirms no required or optional inputs. The description appropriately omits parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the source and data type: '深圳证券交易所-基金产品-基金列表-ETF基金份额' (SZSE fund products - fund list - ETF fund shares) and mentions the return type as pandas.DataFrame. While it lacks an explicit verb like 'list' or 'fetch', the resource is clearly specified and the name itself is descriptive. It is distinguishable from the sibling fund_etf_scale_sse by the 'szse' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as fund_etf_scale_sse, fund_scale_daily_szse, or other ETF fund tools. There is no mention of specific use cases, prerequisites, or exclusions. Users must infer from the name and title alone, which is insufficient for tool selection.
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 already declare the tool read-only, idempotent, and non-destructive. The description adds a return type (pandas.DataFrame) and a source URL, which is some useful context, but it does not disclose behaviors like error handling, rate limits, data scoping, or output contents. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and logically structured with a title, source URL, and docstring-style parameter/return entries. It is easy to scan and does not contain filler, though the title is repeated and the return description is generic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no output schema. It fails to explain what the '基金数据分析' DataFrame actually contains, making it difficult to distinguish from the many other fund analysis tools and to know what to expect from the call. The URL and minimal parameter notes are insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains `symbol` as 基金代码 (fund code) and `timeout` as 'choice of None or a positive float number,' which adds meaning beyond the bare schema types. Since the schema properties have no descriptions, this documentation provides necessary context, though it could go further with format or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '雪球基金-基金数据分析' and a URL, indicating this is a fund data analysis tool, but it does not specify what specific analysis is performed (e.g., performance, risk, holdings). It also does not differentiate from sibling tools like fund_individual_achievement_xq or fund_individual_basic_info_xq, leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides parameter documentation and return type, with no mention of use cases, prerequisites, or exclusions. This provides no practical selection guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal context: it returns a pandas.DataFrame with trading parameter summary, and provides a source URL. However, the URL points to GFEX, not CFFEX, which is a potential source of confusion. No information about rate limits, data freshness, or error behavior is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title and URL. The Python docstring format is recognizable and the parameter/return info is clearly labeled. However, the URL is inconsistent with the tool name (gfex vs cffex) and the title line repeats the annotation title, which adds a little noise. Overall, it is concise but not perfectly clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description gives enough to understand the basic purpose and return type, but it lacks details about the content of the DataFrame and the exact meaning of 'trading parameters'. The URL mismatch also reduces confidence in the tool's data source. Without an output schema, more context about the return structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'date', is described in Chinese as '查询日期' (query date), which adds basic meaning beyond the schema's type and default. The schema description coverage is 0%, so the description must compensate. It does explain what the parameter is for, but it does not specify the expected format (e.g., YYYYMMDD), although the default '20240228' implies it. This is a minimal but adequate explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '中国金融期货交易所-数据-交易参数' (China Financial Futures Exchange - Data - Trading Parameters), which indicates the tool retrieves trading parameters for CFFEX. However, there is no explicit action verb; the docstring's ':return: 交易参数汇总查询' is a noun phrase. The URL (gfex.com.cn) contradicts the tool name (cffex), creating confusion about which exchange is intended. It also does not distinguish this tool from sibling futures_contract_info tools beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 preferred scenarios, exclusions, or comparisons to other futures_contract_info_* tools. The only context is the title and URL, which imply CFFEX-specific data, but this is not explicitly stated in a way that helps 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the source URL and notes the return type (pandas.DataFrame), but does not disclose details such as data volume, pagination, or any quirks about the delivery matching process. With annotations covering the core behavior, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring structure with title, source URL, param, and return. It is not verbose, but the first line duplicates the title already present in annotations, which is slightly redundant. Overall, it is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description bears full responsibility for explaining what the returned DataFrame contains. It only says '交割配对表' (delivery matching table) without specifying columns, row content, or how to interpret the data. It also lacks examples of valid symbol values, making the tool hard to use correctly despite its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It defines :param symbol: as 交割品种 (delivery variety), which gives a general meaning, but does not explain valid values, code format (e.g., 'a' for a specific commodity), or how the default works. This minimal explanation is insufficient for an agent to correctly populate the parameter beyond guessing. Score reflects the lack of actionable detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns the Dalian Commodity Exchange delivery matching table (大连商品交易所-交割配对表), which clearly identifies the specific resource and distinguishes it from sibling tools like futures_delivery_dce and futures_delivery_match_czce. Although it lacks an explicit verb like 'fetch' or 'get', the ':return:' line makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 choose futures_delivery_match_dce over futures_delivery_dce or futures_delivery_match_czce, nor any context about the type of delivery data being queried. This leaves the agent to infer usage solely from the 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?
The description adds only the source URL and return type, which is minimal. Annotations already declare readOnly/idempotent, so the safety profile is covered, but the description doesn't disclose behavioral traits like whether it fetches live data, caching, or how the list is derived. With annotations present, the bar is lower, but the description still provides almost no additional 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the return information and a URL. However, it is a noun phrase rather than a complete sentence, and the structure is a bit fragmented with the ':return' and ':rtype' lines. It earns points for brevity but loses for lack of a clear, complete statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description still lacks critical context. It doesn't mention that it's specifically for foreign commodity futures, what the exchange symbols look like, or how the list is intended to be used. With many sibling tools, an agent needs more context to decide when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the input schema is empty. The baseline for 0 params is 4. The description doesn't mention parameters, but none exist, so no information is missing. It adequately covers the parameter story.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns a list of quote codes that need subscription (需要订阅的行情的代码) and includes a source URL. This is clear enough to understand the core purpose, but it lacks an explicit verb and doesn't differentiate from sibling tools like futures_hq_subscribe_exchange_symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 are sibling tools for foreign commodity realtime, details, and history, but no exclusions or conditions are mentioned. An agent is left without context for proper selection.
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 already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds the daily frequency and the source website, which are useful behavioral details. However, it does not explain what data is returned (e.g., columns, history depth, or whether it is a complete time series).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the essential identity and source. It uses a docstring format with param/return sections, which is conventional and parseable. There is minor redundancy (the title line repeats in the return line), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description fails to specify the structure of the returned DataFrame, including columns, date range, or how the symbol parameter affects the data. Although the single parameter is simple, an agent would not know what to expect from the result. The lack of return-value detail is a significant gap for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' as a string with a default value, providing no description or enum. The description compensates by explicitly listing the two allowed choices: '中证商品期货指数' and '中证商品期货价格指数'. This is meaningful guidance beyond the schema, though it does not explain the difference between the two symbols.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing 中证商品指数 (China Securities commodity index) data at daily frequency, along with a source URL. However, it lacks an explicit verb like 'get' or 'retrieve', making it more of a label than a clear action statement. It does distinguish itself from sibling tools by naming a specific index family and frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling list includes many other futures and index tools, but the description gives no comparison or selection criteria. The only hint is the source URL, which does not help an agent choose between related 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?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds that the return is a pandas DataFrame with spot prices and basis, and provides a source URL. It does not disclose edge cases like invalid dates or non-trading days, but this is a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. The URL and docstring-style params/returns are organized, though the type information duplicates what the schema provides. Overall, it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The lack of output schema and minimal description leave several gaps: exact date format, handling of non-trading days, and differentiation from similarly named tools. The name 'previous' conflicts with the description's 'specific trading day', and without more detail, an agent may not correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It states the date parameter is a trading day/historical date and its type, but it does not specify the expected date format. The URL example uses YYYY-MM-DD while the schema default is YYYYMMDD, creating ambiguity that can lead to incorrect calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves spot prices and corresponding basis for a specific trading day, using a specific verb and resource. However, it does not differentiate from sibling tools like futures_spot_price_daily or futures_spot_price, and the name 'previous' may imply a specific day while the description says any trading day.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The mention of '历史日期' implies historical usage, but there are no alternatives named and no exclusions, leaving the agent to guess among many futures spot 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame) but no additional behavioral traits such as data freshness, coverage limits, or pagination behavior. It does not contradict annotations, but it provides minimal extra insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but not optimally structured. It leads with a long Chinese navigation path, then a URL, and then a docstring-style return type. It could be condensed into a single clear sentence without the redundant path hierarchy, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must fully explain the return value. It merely states that it returns a pandas.DataFrame of RMB FX spot quotes, but provides no details on columns, data frequency, or the set of currency pairs included. This leaves the agent uncertain about the exact nature of the data, especially compared to similar tools like fx_swap_quote.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage vacuously. As per the rubric, the baseline for 0 parameters is 4, since there are no parameter semantics to explain beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns 人民币外汇即期报价 (RMB foreign exchange spot quotes) from a specific source (China Foreign Exchange Trade System), which aligns with the tool name and distinguishes it from siblings like fx_swap_quote or forex_spot_em. However, it lacks an explicit verb like 'get' or 'fetch', and is phrased as a navigation path rather than a direct statement of functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 what data is returned and provides a URL, but does not mention any conditions, exclusions, or comparisons to other FX tools in the sibling list, leaving the agent without decision-making support.
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 already declare readOnlyHint, idempotentHint, and non-destructive. The description adds no behavioral traits beyond the available indices and sample output; it doesn't mention rate limits, authentication, or side effects. It doesn't contradict annotations, so a baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with purpose and valid names, but then includes a large 30-row sample DataFrame and docstring boilerplate, making it unnecessarily long. The 'param name: None' line is confusing and adds noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description provides enough to call it with the default url and a chosen name from the list, and the sample shows the expected output. However, it doesn't explain the meaning of 'open_order', whether the data is historical or current, or how the 'trend' in the name relates to the snapshot output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). The description adds value by listing the valid values for 'name', but 'url' is only described as '网址' (web address), adding no semantics. Defaults are provided in schema. Partial compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves QHKC index data for '大资金动向' (big capital flow) and enumerates the valid index names. It distinguishes itself from generic index tools by its specific focus on capital movement, though it doesn't explicitly name sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The description implies usage by listing the available index names, but doesn't explain when to choose this tool over sibling tools like get_qhkc_index_profit_loss or get_qhkc_fund_position.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type, providing minimal additional context, but does not disclose any behavioral traits such as data update frequency, rate limits, or data scope beyond the index itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, containing only the title, URL, return value, and return type. It is compact without excessive waste, though the formatting is a bit raw (colon markers in a block). For a no-parameter tool, this level of conciseness is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description only states that it returns the Bloomberg Billionaires Index as a DataFrame, but does not describe the data's contents, columns, or whether it represents current snapshot vs. historical data. The minimal description is sufficient for a simple retrieval but leaves gaps in understanding exactly what data will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to describe. The baseline score of 4 applies because the input schema is empty and fully covers all parameters (none exist), and the description does not need to compensate for any missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Bloomberg Billionaires Index' and a :return: of 彭博亿万富豪指数 as a pandas DataFrame, which implies it retrieves the index data. However, there is no explicit verb like 'get' or 'list', and it does not differentiate from the sibling tool index_bloomberg_billionaires_hist, making the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 historical vs. current data, nor does it reference any sibling tools or conditions for use, leaving the agent without direction on 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?
Annotations already declare the tool read-only and idempotent, so the safety profile is covered. However, the description only adds the source URL and return type, with no additional behavioral context like network dependencies, data limits, or error conditions, which is a notable gap for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but its structure is a terse Python docstring format. It lacks a clear, human-readable summary and omits potentially useful details, yet it contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description should clarify what the returned DataFrame contains. It merely repeats the title '产业指数' and gives a type, leaving column details, data meaning, and update frequency ambiguous. This is inadequate for an agent to reliably interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making schema coverage trivially 100%. The description does not need to explain parameter semantics, and no parameter information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource '产业指数' (industry index) from 财新数据 and specifies the return type as pandas.DataFrame, indicating a clear data retrieval function. However, it lacks an explicit verb and does not differentiate itself from sibling index tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 index_dei_cx or other index-related tools. There is no mention of data coverage, frequency, or any prerequisites, leaving the agent uninformed about selection criteria.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds only a return type (pandas.DataFrame) and a source URL, but no behavioral details such as data lag, column structure, or rate limits. It repeats the title without enriching beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: the first line and the :return: line are identical, and the URL is likely not actionable for an AI agent. The repetition wastes space without adding informational value, so it is not a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description provides the essential identity (index, metric, timeframe, return type). However, it lacks differentiation from closely related sibling tools (e.g., the non-min version) and does not describe the DataFrame's typical columns or update frequency, leaving gaps for an agent deciding among the many QVIX tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with 0 parameters, and schema_description_coverage is high (100% effectively), so the baseline is 4. The description's mention of return type adds slight context for what the caller receives, though parameter explanation is not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: 中证1000股指期权波动率指数QVIX-分时 (CSI 1000 index options volatility index QVIX intraday). It distinguishes from non-min siblings by including '分时' (minute-level), matching the tool name's 'min' suffix. However, it lacks an explicit verb like 'fetch' or 'retrieve', but the :return: statement implies it returns such 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/5Does 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. There is no mention of suitable contexts, exclusions, or references to sibling tools (e.g., index_option_1000index_qvix without 'min'). The URL is a data source but provides no usage direction.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no additional behavioral context such as data volume, time range, or limitations; it only states the return type and source URL, which do not disclose behavioral traits. Minimal value is added beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes redundant repetition of the title ('財新中國 PMI-綜合 PMI' appears twice). It uses a multi-line structure with a URL and docstring return annotations, but could be more compact and written as a coherent sentence. Some information is useful, but there is noticeable redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description only states that the return type is a pandas DataFrame and provides the source URL. It does not describe the columns, time series coverage, or any filtering options. For a simple index retrieval tool, this lacks detail about the actual data contents, making it incomplete for agents that need to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is no parameter guidance needed. The input schema is empty and the description correctly implies the tool takes no arguments. The zero-parameter baseline of 4 is appropriate since the description does not need to explain any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning the Caixin China Composite PMI index report, with a source URL and return type. It clearly names the specific resource (Composite PMI) and distinguishes it from sibling PMI tools such as manufacturing or services. However, it lacks an explicit verb, reading more like a label than a full action-oriented 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/5Does 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 alternative PMI index tools or other macroeconomic data tools. There are no exclusions, prerequisites, or context about use cases, leaving the agent without direction on 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?
Annotations already convey that the tool is read-only, idempotent, and non-destructive. The description adds only the data source and return type, but discloses no other behavioral traits such as data frequency, historical range, or release delay. Thus it contributes little beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief—a title, URL, and standard return annotations—so it is concise and front-loaded. It wastes minimal space, though it does repeat the tool name almost verbatim, which is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only macro indicator, the description gives the series name and return type, which is somewhat useful. However, there is no output schema, and the description does not describe the structure of the returned DataFrame (e.g., columns, date range), leaving some ambiguity about what data is actually returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is no parameter semantics to clarify. With no parameters, the baseline of 4 is appropriate, and the description does not need to compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning the Eastmoney Canada core CPI monthly rate, but it does so largely by restating the tool name in Chinese without a clear verb phrase. It gives the source and return type, and the term '月率' hints at the monthly frequency, but it does not explicitly contrast with the yearly sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the closely related `macro_canada_core_cpi_yearly` or `macro_canada_cpi_monthly` alternatives. Usage context is only implied by the tool name and the URL, not by any explicit recommendation or exclusion.
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?
The description adds the return type (pandas.DataFrame) and a data source URL, which is useful. Given that annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, the description does not need to restate safety, but it could disclose more about data content or behavior beyond simply returning the index.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is merely a concatenation of a title, a URL, and a return type. It avoids verbosity, but it is not a coherent, well-structured sentence that explains the tool clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter details, the description should explain what the returned DataFrame contains (e.g., columns, frequency) and any other relevant context. It only provides the index name and a source URL, which is insufficient for an agent to fully interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already reflects this (100% coverage). With no parameters to document, the description is not expected to add parameter information, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '超灵便型船运价指数' (Supramax shipping freight index) and provides a source URL, but lacks an explicit verb like 'retrieve' or 'get.' It is distinct from sibling shipping indices by name, but doesn't differentiate beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not state any exclusions, prerequisites, or preferred contexts, leaving the agent without enough information to select it over sibling shipping index 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and a source URL, which are useful but minimal. It does not disclose data granularity, column structure, or any potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, totaling three lines. It leads with the key identifier and includes a source URL and return type. However, the format is a raw docstring with minimal structure; the URL is a long string that may clutter the description without adding immediate semantic value. It is concise but not polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no parameters, the description should compensate by explaining what data is returned, its structure, or the time range. The description merely restates the name and gives a URL, leaving the agent to guess the DataFrame columns, whether it is historical or current, and the update frequency. This is inadequate for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides no constraints. The baseline for 0 parameters is 4, and the description does not need to explain parameters. No value is lost here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '建材指数' (Building Materials Index) and a source URL, which conveys the resource, but lacks a specific verb like 'returns' or 'fetches'. It is essentially the title repeated, providing no scope details (e.g., historical vs. current data). This does not distinguish it from similar macro indices like macro_china_energy_index or macro_china_construction_price_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or exclusions. The only implicit signal is the name itself, which is already available to the agent without reading 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety. The description adds only a source URL and return type (DataFrame), but does not disclose what the CPI data looks like (e.g., time series, columns, frequency) or any other behavior. This is minimal added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the ':return:' line just repeats the title, adding redundancy. The source URL is useful, but the overall structure is loose and could be condensed into a single meaningful sentence. It lacks a clear, front-loaded explanation of the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description should at least explain the nature of the returned CPI data. It only says 'China CPI' and a DataFrame, without specifying time period, frequency, columns, or data source details beyond the URL. This is insufficient for a user to understand what will be returned, making the tool underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has no properties, so schema coverage is 100%. With no parameters to document, the description does not need to compensate; the baseline for zero parameters is 4. The description confirms it expects no input, aligning with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides China's Consumer Price Index (CPI) data from East Money, including a source URL. The verb is implied rather than explicit, and the tool name 'macro_china_cpi' plus the Chinese title unambiguously identify the resource. However, it does not differentiate from siblings like macro_china_cpi_monthly or macro_china_cpi_yearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the distinction between monthly, yearly, or overall CPI tools, nor any context for selecting this one. It simply states the title and source, leaving the agent without decision criteria.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type but no extra behavioral traits like date ranges, refresh behavior, or data granularity. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a few short lines, but it reads like a fragmented docstring rather than a structured description. It includes the URL and return type in a non-sentential format, and while it is not verbose, it lacks a clear lead sentence that would make it easier to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should compensate by explaining what the returned DataFrame contains (e.g., time series columns, date, revenue amount). It only says '财政收入' and return type, leaving the data structure and frequency unclear, which is insufficient for an AI agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully documents the absence of arguments. The description adds nothing beyond the schema, but with no parameters, there is nothing to explain; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides the tool's Chinese label '东方财富-财政收入' (Eastmoney - Fiscal Revenue) and a source URL, which identifies the resource but lacks an explicit verb like 'retrieves'. It distinguishes itself from sibling macro tools by being specifically about fiscal revenue, but the action is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no typical use cases, and no context on how fiscal revenue data is typically accessed. The description is just a data source reference with no practical usage direction.
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?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover the basic safety profile. The description adds no further behavioral context such as data freshness, pagination, or potential errors. It only mentions the return type (DataFrame), which is not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant content by repeating 'LPR品种详细数据' and adding a docstring-style return type. The URL may be informative but does not help an AI agent select or invoke the tool. It is concise overall, but not every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description leaves gaps about what the LPR data actually includes (e.g., tenors, historical range, columns). An agent would need more detail to understand what to expect from the returned DataFrame. The description is minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and the description need not explain parameter details. The baseline for zero-parameter tools is 4, and the description does not introduce any confusion about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as LPR and indicates 'detailed data', which makes it clear the tool provides LPR information. However, it uses a noun phrase rather than an explicit verb like 'retrieve' or 'get', and does not explicitly distinguish itself from sibling macro tools beyond the LPR topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling macro tools. It does not state any use cases, prerequisites, or alternatives. The description simply provides a source URL and return type, leaving the agent to guess the appropriate context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the return type (pandas.DataFrame) and the data source URL, which are useful but do not disclose additional behavior like error handling, rate limits, or data range. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it includes a long URL that is not essential to understanding the tool's function. The structure is docstring-like with ':return:' and ':rtype:', which is organized but somewhat under-specified. It earns a middle score for brevity but lacks polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description only reiterates the topic and gives a URL. It does not explain the data's time range, granularity, or columns, which could leave the agent uncertain about what the DataFrame contains. The simplicity of the tool raises the bar for clarity, but the description remains minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 semantics, and it correctly remains silent on this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says '手机出货量' (mobile phone shipments) and specifies the return type, but it lacks an explicit verb like 'get' or 'return'. It identifies the resource but is essentially a label with a data source URL, not a clear statement of function. It is distinguishable from siblings by its unique topic, but the purpose is only implicitly conveyed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 context, prerequisites, or exclusions. Among many macro_china_* siblings, there is no situational differentiation.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. However, the description introduces a confusing instruction to set 'symbol' to None, which does not match any input parameter in the schema (which uses 'indicator'), potentially misleading an agent. It also omits details on rate limits or any other runtime constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is reasonably short and front-loaded with the title and URL. The parameter and return structure is logical, but the confusing 'symbol' reference serves as a distractor, and a quick example of a valid path and indicator would make it more actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a generic interface with five parameters and no output schema, the description should explain valid path values, indicator formats, and the overall return structure. The current text only promises a pandas.DataFrame and leaves the agent to discover path/indicator conventions elsewhere, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description defines all five parameters, including concrete period format examples ('LAST10', '2016-2023', '2016-') and the region/indicator interaction. While the 'symbol' wording is a minor inconsistency, the description adds substantial meaning beyond the bare schema, which is especially valuable given 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the National Bureau of Statistics regional data general interface, with a direct data source link. It distinguishes itself from sibling tools like macro_china_nbs_nation by focusing on region-level data, although the verb 'retrieve' is implied rather than stated explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_china_nbs_nation or macro_cnbs. The description only lists parameters and return type, leaving the agent to infer the appropriate use case from the tool name.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds the source URL and the return type (pandas.DataFrame), but does not disclose any additional behavioral traits such as rate limits, data freshness, or how the two city parameters affect the result. This is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring format with title, URL, params, and return. It is front-loaded with the Chinese title and includes the source URL, which is useful. No unnecessary filler, though the param descriptions are minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two string parameters, simple annotations, and no output schema, the description should clarify what the tool returns and how the parameters work. It only states it returns the new house price index as a DataFrame, but does not explain the time period, geographic scope, or how the two city parameters are used. This is a significant gap for an agent attempting to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It states that city_first and city_second are cities and directs users to the target website for a city list, which adds some meaning. However, it does not explain the relationship between the two cities (e.g., comparison, separate queries) or provide any domain-specific guidance on valid values, leaving the agent with insufficient information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing China's new house price index, with a data source URL and a return type of DataFrame. However, it lacks an explicit verb like 'fetch' or 'retrieve', and does not distinguish itself from the many other macro_china_* tools beyond its name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only provides a data source URL and param/return documentation, but does not mention any exclusions, prerequisites, or comparison to sibling tools like macro_china_real_estate or macro_china_house_price_index.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds only a data source URL and return type, but no behavioral context such as data scope, update frequency, or limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and compact, but the structure is fragmented, mixing a raw URL with docstring-style :return: and :rtype: lines. It is not poorly sized, but the format is not polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter data retrieval tool, the description does not specify whether the data is historical or current, what columns are present, or the time range. The presence of an output schema would mitigate this, but there is none, so the description carries the full burden and falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for this case is 4. The description correctly notes the return type and does not need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's resource as the Capesize Freight Index (BCI) and indicates it returns a pandas DataFrame. It distinguishes itself from sibling shipping tools by naming the specific index, though it lacks an explicit verb like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_shipping_bdi, macro_shipping_bpi, or macro_shipping_bcti. The description does not mention any context, prerequisites, 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?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the data source URL and date range, but it contains a significant internal contradiction: the return description claims the report is 'foreign exchange' while the tool name and main description say 'commodities'. This misdescribes the output and reduces trustworthiness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main subject. However, the return line is redundant and contains a factual error (foreign exchange instead of commodities), so not every sentence earns its place. A correct return line would make it more concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description provides some necessary context (date range, source URL) and annotations supply safety details. However, the erroneous return description makes it incomplete, and the description does not explain what 'non-commercial holdings' means or what columns/format the DataFrame contains. With no output schema, better return documentation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema provides no information to clarify. Per baseline for 0 params, the description need not add parameter semantics. It correctly includes return type and data source, which is sufficient given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the tool as a U.S. CFTC commodity non-commercial holdings report with a specific date range, which distinguishes it from merchant or currency holding siblings. However, it lacks an explicit action verb, and the return line erroneously says 'foreign exchange' instead of 'commodities', introducing some confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many similar CFTC holding tools (e.g., merchant goods, merchant currency, or non-commercial holdings). The URL provides a data source, not usage context, and no alternatives or exclusions are mentioned.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type but discloses nothing about network behavior, latency, pagination, or data limitations. It is a minimal addition beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, containing a title, a URL, and return type information. It is not verbose, but it reads as a docstring fragment rather than a well-structured description. The lack of a proper sentence structure makes it slightly less accessible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain the returned data. It only says it returns 'artist traffic value' as a DataFrame, leaving column names, row semantics, and data granularity unspecified. For a simple tool this could be acceptable, but the ambiguity makes it incomplete for an agent that must interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is empty and the baseline is 4. The description correctly focuses on the return value, which is the only meaningful semantic here. No additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns artist traffic value from endata.com.cn, and specifies the return type as pandas.DataFrame. This is a specific verb+resource pairing, though it does not explicitly differentiate from sibling tools like business_value_artist, which might overlap in domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is a zero-parameter function with no context on use cases, prerequisites, or complementary tools. The only implied usage is 'call it to get artist traffic value'.
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 already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds the data source URL and return type (DataFrame of fees), but doesn't disclose potential edge cases such as the parameter default/choice mismatch, which is more of a parameter semantics issue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the title and URL. The docstring format is standard and compact, though the :param: and :return: lines are slightly redundant with the title. Each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% schema description coverage, the description's minimal ':return: 期权手续费' is insufficient to understand the exact data structure. The parameter mismatch further undermines completeness, leaving an agent uncertain about how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists allowed symbol values (exchanges and '所有'), but the schema default is '工业硅期权', which is not in that list. This contradiction creates confusion about valid inputs. The schema has 0% description coverage, so the description must compensate but instead introduces inconsistency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches commodity option trading fees (九期网-商品期权手续费) from a specific URL, which is a precise verb+resource. It doesn't explicitly contrast with sibling fee tools, but the resource is specific enough to distinguish 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/5Does 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 like futures_fees_info or option_comm_symbol. The description only includes a parameter docstring without any context on selection criteria or prerequisites.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), but offers no additional behavioral traits such as pagination, rate limits, or error handling, which is acceptable given the strong annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but unstructured, mixing a title, URL, and docstring fragments. The title repeats the annotation's title, which is redundant. It is not verbose, but the fragmented structure prevents it from being a clean, purpose-built description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a data-retrieval tool with no output schema. It states the return type but not the actual contents or columns of '每日统计' (daily statistics). There is no information about date range behavior, data granularity, or limitations, leaving significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'date' with no description coverage. The description adds the semantic meaning '交易日' (trading day), which is useful but does not specify the expected format beyond the default value's hint (YYYYMMDD). It partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as Shanghai Stock Exchange stock options daily statistics, and the URL provides a source hint. However, it lacks an explicit verb (e.g., 'get', 'fetch') and does not distinguish from sibling tools like option_daily_stats_szse, so it doesn't fully meet the top 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/5Does 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 merely states the resource and parameters, with no context about selection criteria, prerequisites, or exclusions compared to other option data 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to restate safety. It adds context by listing the data sources (SSE, SZSE, CFFEX URLs) and the return type (pandas.DataFrame). However, it does not disclose potential caveats like data availability timing or behavior when a requested contract month is invalid, which is useful but not critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose relative to its content. It starts with a purpose sentence, then a long sentence listing instruments, followed by four exchange URLs that are not actionable for an agent. The instrument list is repeated in the :param section, creating redundancy. The structure is acceptable, but the waste reduces clarity and focus.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the purpose, parameters, and return type, but leaves critical details unspecified. There is no output schema, so the agent is not told what columns the DataFrame contains (e.g., open, high, low, close, volume). The end_month parameter format is also ambiguous, which is important for contract selection. The listing of covered options is helpful, but the tool feels incomplete for programmatic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema properties have no descriptions (0% coverage), so the description must compensate. It provides a list of allowed values for symbol (9 choices) and a comment for end_month ("2003; 2020年3月到期的期权"). The symbol list adds real meaning, but the end_month explanation is ambiguous and appears garbled, leaving format expectations unclear despite the default '2306'. Thus it partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides current trading day option market data ("期权当前交易日的行情数据") and enumerates specific underlying instruments (e.g., 华夏上证50ETF期权, 沪深300股指期权). It also lists source URLs and return type, which gives a concrete scope. However, it does not explicitly distinguish itself from sibling tools like option_current_em, so differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no exclusions or references to other tools for historical data or other option types. The only hint is the temporal scope ("当前交易日"), but this is not framed as usage guidance.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that the return is a pandas DataFrame of volume-price data, but does not disclose any caveats such as data delays, symbol validity, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and each line adds information (summary, parameter, return type), though it is presented as a docstring rather than a polished prose description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 the many sibling option tools, the description should have specified the SSE scope and the exact data fields returned. It currently only says 'option volume-price data,' which is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that 'symbol' is the option code and is a string, which is meaningful given the schema has no per-property description. However, it does not provide format examples or how to obtain valid codes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Sina Finance - Options - Real-time data' and indicates the return is 'option volume-price data', but it does not specify that this is for SSE options or that it returns spot prices, making it hard to distinguish from sibling tools like option_sse_greeks_sina or option_sse_minute_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description only includes a docstring with parameter and return types, with no contextual instructions for when to select this tool over others.
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?
The description adds that the tool returns a pandas DataFrame and is sourced from a specific East Money URL, and scopes the data to the current day (当日). This goes beyond the annotations (readOnly, idempotent, non-destructive), but it does not disclose potential caveats such as data columns, freshness, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with only the title, URL, return type, and rtype. It is concise and front-loaded, but the title repetition and lack of structured explanation prevent a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what the DataFrame contains. It only says '板块异动详情页' (sector change detail page) and the return type, without describing columns, meaning of '异动', or any limitations. This is insufficient for a no-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides everything needed. The description does not need to add parameter-specific semantics; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the title '东方财富-行情中心-当日板块异动详情' and adds a URL and return type, but lacks a verb and does not explain what '板块异动详情' entails or distinguish it from sibling tools like stock_board_concept_spot_em. It is more than a pure tautology because of the URL and rtype, but the core purpose is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other stock board tools. It neither states appropriate use cases nor mentions alternatives, leaving the agent to infer selection criteria from the name alone.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the data source URL and return type (pandas.DataFrame), which is useful but does not disclose details like data freshness or potential limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the title-like phrase, a URL, and a return type. It is front-loaded and has no fluff, though it might benefit from a clearer statement of functionality. Still, it earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description carries the burden of explaining what the returned DataFrame contains. It merely says '概念时间表' without describing columns, date ranges, or whether it's a summary or historical timeline. The URL is given but not accessible to the agent. This is insufficient for an agent to confidently use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is empty, so the description correctly implies no input is needed. The baseline for 0 parameters is 4, and the description confirms the tool takes no arguments by not mentioning any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (同花顺 concept board time table) and provides a source URL, but it's essentially a noun phrase without a clear verb. It does not differentiate from sibling concept board tools like stock_board_concept_spot_em or stock_board_concept_hist_em, and the term '概念时间表' (concept time table) is vague about what exactly is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or related tools. The description only states what it returns, not the context in which it should be preferred.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is modest extra context. It does not disclose rate limits, pagination, or data content specifics, but with annotations present, the bar is lower and the added value is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title, followed by a URL and a clean param/return docstring. It has no unnecessary fluff, but the title is repeated verbatim in the description, which is slightly wasteful. Overall it is compact and structured, though not perfectly sharp.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description is the sole source for understanding the return value. It only repeats the title as the return description, which is circular and uninformative. It does not explain what historical rating columns are included, the data granularity, or how the symbol maps to the URL. For a niche Chinese financial data tool, this is insufficient context for an agent to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only provides a Chinese label '股票代码' and type 'str', which is redundant with the parameter name and schema type. It does not explain the format (e.g., 6-digit code), how to specify exchange, or what values are valid. This is minimal compensation for a zero-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific data product: 东方财富网-数据中心-特色数据-千股千评-综合评价-历史评分. This distinguishes it from sibling stock_comment_detail tools by specifying the '综合评价-历史评分' subcategory. However, it lacks an explicit verb like 'retrieves' or 'gets', and reads more as a title than a functional statement, preventing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when to choose this over stock_comment_em or other stock_comment_detail_* variants, nor any exclusions or prerequisites. The only context is a URL and parameter documentation, which offer no usage direction.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and the source URL, which is useful context. However, it does not describe data contents, date handling, or potential limitations like pagination, making the behavioral disclosure minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but formatted as a docstring with a URL, parameter lines, and return info. It is not front-loaded with a clear summary sentence; the title line serves as a label. Each part is useful, but the structure is slightly clunky.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what the DataFrame contains. It merely states '每日统计' without listing columns, meaning of data, or any example. Given the tool's apparent complexity (daily block trade statistics), this is a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides Chinese labels (开始日期, 结束日期) that add meaning beyond the schema's plain 'string' types. However, it does not specify the expected date format (beyond the default '20220105') or other constraints, leaving room for interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Eastmoney's block trade daily statistics, and includes a direct URL. It lacks an explicit action verb but implies a data retrieval function. It does not differentiate from sibling tools like stock_dzjy_sctj, but the name and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase '每日统计' implies daily aggregate stats, but sibling tools are not mentioned, and no exclusions or alternative references are provided. The parameter docstring gives basic input instructions but no contextual 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat safety. The description adds the return type (pandas.DataFrame) and the data source URL, but does not disclose whether the tool returns data for all stocks or a specific stock, the date format, or potential pagination. This omission is significant given the many similar sibling tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and follows a standard docstring format with :param and :return. It includes the Chinese title and URL, which provide helpful context, without any fluff. While it is not overly verbose, it could be more front-loaded with a clear action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description's ':return: 十大股东' and ':rtype: pandas.DataFrame' are minimal and do not explain the DataFrame's columns or scope. The description does not mention that this tool appears to provide statistics across all stocks for a given report period, nor does it clarify how it differs from the many sibling holding-analysis tools. This is a significant gap for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'date' with a type and default, so the description's ':param date: 报告期' (report period) adds essential meaning. However, it does not specify the expected format (e.g., YYYYMMDD) or the allowed range, though the default '20210930' implies the format. Given the low schema coverage, the description partially compensates but could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the Eastmoney data center shareholder analysis page for top 10 shareholders holding statistics, including a URL and return type. It specifies '十大股东' (top 10 shareholders) and '股东持股统计' (shareholder holding statistics), which distinguishes it from sibling tools like holding change or holding detail. However, it lacks an explicit verb like 'get' or 'fetch', but the return docstring implies retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_gdfx_holding_change_em or stock_gdfx_holding_detail_em. It only documents the date parameter and return type, without mentioning exclusions, prerequisites, or specific use cases. This leaves the agent to infer usage from the tool name and siblings.
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 already declare readOnlyHint=true and idempotentHint=true. The description adds that the data is from East Money's market center and returns a pandas.DataFrame, but does not disclose any further behavior like data latency or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first line duplicates the title annotation. The URL and return type are useful, but the redundant line wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-param, no-output-schema tool, the description only states it returns a DataFrame of index quotes. It lacks details on which indices, columns, or the nature of the data, making it incomplete for an agent to understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% with an empty object. Per the rubric, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '港股-指数实时行情' (HK index real-time quotes) which indicates the resource, but it is a noun phrase without a verb and essentially repeats the title annotation. It does not distinguish from sibling tools like stock_hk_index_spot_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only gives a source URL and return type, with no mention of use cases 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds minimal behavioral context: it specifies the return type as list and includes a source URL, but it does not reveal any operational details such as rate limits, response structure beyond 'list', or potential empty results. Without annotations this would be insufficient, but with them it adds little extra.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a docstring format with title, source URL, param, and return sections. It is front-loaded with the tool's purpose. The URL is somewhat verbose but serves as a source reference. Overall it is efficient and avoids unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the basic input and return type. However, there is no output schema, so the description should clarify what the list contains (e.g., whether it's just name strings or includes dates). The optional nature of the symbol (required 0, default) is not mentioned in the description, and edge-case behavior is absent. It is minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'symbol' with a string type and default, but no description. The description compensates with ':param symbol: 股票代码' (stock code), giving the parameter clear meaning. It does not specify format (e.g., exchange prefix or digit length), but the default '000503' and Chinese context make it reasonably clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Sina Finance stock former names (新浪财经-股票曾用名) for a given symbol. It identifies the specific resource and action, though it does not explicitly differentiate from sibling stock_info_sz_change_name which may cover a similar scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 are siblings like stock_info_sz_change_name and many other stock_info tools, but the description does not mention any exclusions, alternatives, or specific use cases. The agent is left to infer usage solely from the name.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the parameter is a start time and the return is a pandas DataFrame, but does not disclose pagination, rate limits, or the scope of the statistics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is compact, using a docstring-style format with source, URL, param, and return. However, it repeats the title information and includes a URL that may be of limited value to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains, but it only repeats '机构调研统计' without detail. It also does not clarify the date range behavior or how the statistics are aggregated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'date' with zero description coverage. The description labels it as '开始时间' (start time), which adds some meaning, but does not specify the expected format (e.g., YYYYMMDD) or that it defaults to '20220101'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Eastmoney's institutional research statistics and includes the source URL. It specifies the resource and data type, though it lacks an explicit action verb and does not differentiate from the sibling tool stock_jgdy_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only states the data source and parameter, without any context about use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds only the return type (pandas.DataFrame) and a URL, but no behavioral context such as what data is included, whether it is real-time/historical, or any rate limits. This adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is repetitive: the Chinese title appears twice ('龙虎榜-机构席位成交明细' in the title and in the :return: line). The URL is additional but not descriptive. It is front-loaded but under-specified, making it concise yet redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should describe the returned data content. It only provides a return type and a repeated title, not what columns or data it contains. The description is insufficient for an agent to understand what data will be returned or how to interpret it, given the tool's clear niche.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not applicable. The baseline of 4 is appropriate because there are no parameters for the description to explain, and the schema is empty (100% coverage). The description correctly does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource as '龙虎榜-机构席位成交明细' (Dragon-Tiger List institutional seat transaction details) and includes a source URL. This is clear enough to distinguish it from other stock_lhb_* sibling tools, though it lacks an explicit verb like 'get' or 'retrieve'. The Chinese title is specific and informative, so purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of use cases, context, exclusions, or alternative tools. It simply states the resource name and return type without any situational guidance.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the bar is lower. The description adds only a source URL and return type (pandas.DataFrame), but no additional behavioral traits such as pagination, data freshness, or default selection of columns. This is minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the title and URL, then the return type. It avoids verbosity, though it is more of a docstring fragment than a structured explanation. The brevity is appropriate for a simple zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description identifies the data source, scope (Shanghai Main Board), and return type, but does not explain what fields the DataFrame contains, how the data is structured, or what 'IPO审核信息' includes. With no output schema, this leaves the agent without critical information about the returned data's content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and there is nothing to describe. Per the baseline for zero-parameter tools, the description is sufficient even though it adds no parameter-specific semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly identify the resource as IPO review information for the Shanghai Main Board from Eastmoney, and the return type is stated. However, there is no explicit verb like 'get' or 'query', relying on the noun phrase, so it is clear but not fully action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 sibling tools such as stock_register_sz, stock_register_cyb, or stock_register_all_em. There are no context indicators, alternatives, or exclusions, leaving the agent to guess based on the name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the return type (pandas.DataFrame) and the parameter meaning, but does not disclose additional behavioral details such as the DataFrame's columns, date range constraints, or any rate limits. This is minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably short but mixes a Chinese title, a URL, and Python docstring format (param/return lines). The title is redundant with the annotation title, and the structure is somewhat fragmented, though it does not waste many words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, but the description only vaguely states that the return is '每日股票情况' (daily stock situation). It does not describe what data is contained in the DataFrame, how the default date is used, whether other formats are accepted, or any error conditions. With no output schema, the description should provide more substance about the return value and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a type and default for 'date' with no description. The description adds that the parameter is a trading day (交易日) and specifies it is a string. This gives some meaning beyond the schema, but it does not specify the expected format (beyond the default example) or any valid range, leaving gaps for a 0% schema description coverage case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as daily stock trading overview data from the Shanghai Stock Exchange, with a specific URL and the Chinese hierarchical path. However, it lacks a clear verb (e.g., 'fetch', 'get') and does not explicitly distinguish itself from similar sibling tools like stock_sse_summary, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the data source and parameter, with no mention of use cases, exclusions, or related tools. The implied usage is present 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?
Beyond the annotations (readOnly, openWorld, idempotent), the description adds no behavioral context. It does not disclose symbol format requirements, date format expectations, or any data source quirks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with exactly the needed info: source, URL, parameters, return type. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description leaves the return content vague. It also lacks usage guidance and parameter format details. For a simple data retrieval tool, it is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define parameters. It offers only direct translations ('股票代码', '开始日期', '结束日期') that add little beyond the parameter names and the schema defaults. No format constraints or examples are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides East Money US stock intraday minute-level quotes, with a source URL and return type. The term '每日分时行情' distinguishes it from daily historical and real-time spot sibling 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/5Does 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 like stock_us_hist (daily) or stock_us_spot_em (spot). The description does not mention any prerequisites 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description's burden is low. It adds only that the return type is a pandas DataFrame, with no detail on output structure, data scope, or any potential quirks. No new behavioral context is disclosed beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear title, a reference URL, and structured docstring-style param/return info. The URL is somewhat extraneous but not distracting, and each line earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description provides core input and output information, but it fails to explain what the returned DataFrame actually contains (e.g., columns, rows, time period). Since there is no output schema, more detail is needed to fully inform an agent about the tool's expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description identifies the only parameter, 'symbol', as a stock code (股票代码) and specifies its type as str. This adds basic meaning since the schema has no description. However, it does not explain the required format (e.g., exchange prefix), although the default 'SZ000895' serves as a partial hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Eastmoney's DuPont analysis peer comparison, distinguishing it from sibling comparison tools like growth or valuation comparisons via the specific '杜邦分析' term. It lacks an explicit verb like 'get' or 'retrieve', but the tool name and context make the action clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative comparison tools. It does not mention any alternatives, exclusions, or specific scenarios, leaving the agent to infer usage solely from the tool name and title.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context: it mentions the return type (pandas.DataFrame) and source URL. It does not disclose any quirks like data adjustment policies, date format expectations, or whether the defaults in the schema have special meaning. With annotations covering the safety aspect, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured docstring with sections for source, URL, parameters, and return type. It front-loads the data source and is free of redundant fluff, though the URL line is arguably unnecessary for an agent. Overall, it is concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 optional params, no output schema), and the description states the return type. However, it lacks crucial details for an agent: exact date format, the meaning of the returned DataFrame's columns, and how this tool differs from similar index tools. Annotations cover the safety profile, and the schema provides defaults, but the description alone would not fully guide correct invocation without inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description partially compensates for the 'symbol' parameter by explaining the market prefixes (sz, sh, csi) and providing an example (csi931151). However, start_date and end_date are only labeled '开始时间' and '结束时间' without specifying the expected format (e.g., YYYYMMDD). The defaults in the schema hint at the format, but the description does not clarify it explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource ('东方财富网-股票指数数据', i.e., Eastmoney stock index data) and includes a URL, but lacks an explicit action verb like 'fetch' or 'query'. The name and parameters imply historical daily data, but the description itself does not specify granularity (daily vs. spot vs. minute), making it ambiguous among sibling index 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/5Does 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 sibling list contains many similar index tools (stock_zh_index_daily, stock_zh_index_daily_tx, index_zh_a_hist, etc.), but the description does not differentiate them or state use cases. The docstring only covers parameter definitions, not selection criteria.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns a pandas DataFrame, which is useful but does not disclose other behavioral details such as pagination, rate limits, or the exact structure of the returned 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring, containing only the essential elements: a title, URL, parameters, and return type. It avoids unnecessary verbosity, though the duplicated typo and URL could be considered minor clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return value more concretely. It only says ':return: 可转债发行' (returns convertible bond issuance), which is vague. The parameters and annotations for read-only behavior are adequate, but the lack of detail about the resulting DataFrame columns or scope leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents the parameters with ':param start_date: 开始统计时间' and ':type start_date: str', which adds meaning beyond the schema. However, for end_date it erroneously repeats '开始统计时间' instead of '结束统计时间', providing misleading semantics for that parameter. This typo undermines the usefulness of the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose through the title line '巨潮资讯-数据中心-专题统计-债券报表-债券发行-可转债发行', which specifies the resource (convertible bond issuance) and source (CNInfo). It distinguishes itself from sibling bond issuance tools by naming '可转债发行' specifically. However, it lacks an explicit action verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states the data source and topic, with no mention of scenarios, exclusions, or sibling tools. The intended use must be inferred entirely from the title and 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no behavioral context beyond the annotations—no mention of web fetching, rate limits, authentication, or potential failure modes. It does not contradict annotations, but also provides no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a docstring with :param: and :return: sections, which is reasonably structured but not front-loaded with a high-level summary. It includes useful parameter choices and the URL but is somewhat verbose for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides the return type and the general meaning. It covers parameter choices and references the index list tool, but lacks context on data shape, date handling, error behavior, and differentiation from sibling bond index tools, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions or enums (coverage 0%), but the description lists all allowed values for indicator and period, and references available_bond_index() for index_category. This adds essential meaning beyond the schema, though it does not explain the semantics of each choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns '指定指数的指定指标的指定期限分段数据' (segment data for a specified index, indicator, and period) from the China Bond Index family (中债指数族系). This is a clear purpose, but it does not differentiate from sibling tools like bond_composite_index_cbond or bond_new_composite_index_cbond, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other bond index tools. The only hint is a reference to available_bond_index() for index_category, but no explicit comparisons or exclusions 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description contributes only the source URL and return type, with no additional behavioral details such as data freshness, network dependency, or pagination. This adds minimal value beyond structured 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a title, source URL, and return type. It avoids verbosity, though it is too sparse to fully convey the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify the returned data's structure and scope. The phrase '可转债行情' is vague and does not specify DataFrame columns, coverage, or whether it is a snapshot or historical data. For a simple no-parameter tool, the return value is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is no parametric ambiguity. The description does not need to explain parameters, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool returns convertible bond market quotes (可转债行情) from the THS data center, with a source URL and pandas DataFrame return type. However, it lacks an explicit verb and does not differentiate it from sibling tools like bond_zh_cov_info or bond_zh_hs_cov_spot beyond the '_ths' source suffix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 state prerequisites, exclusions, or selection criteria, leaving the agent to infer appropriate usage from the name and source only.
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 already declare read-only, idempotent, and non-destructive behavior, so the description's main additions are the source URL and the pandas.DataFrame return type. It does not disclose deeper behavioral nuances like column contents or data currency, but it doesn't contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by a source URL and standard docstring entries for parameter and return. Every line carries some information, though it is somewhat terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description provides the essential resource, source, and return type. However, it omits practical details like supported year ranges or ranking scope, leaving room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description is expected to compensate. It only states that 'year' is a string for the query year, which adds little beyond the parameter name and default. No format examples, valid range, or domain-specific clarification is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a historical ranking list of fund company management scale (AUM) from Eastmoney, which identifies both the resource and the action. It doesn't explicitly contrast with sibling tools like fund_aum_em or fund_aum_trend_em, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives such as fund_aum_em or fund_scale_change_em. The description only provides parameter and return documentation, leaving the selection criteria entirely to the agent.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the return type (pandas.DataFrame) and a source URL; it does not disclose pagination, data freshness, or column details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, containing only a title, a URL, and return type info. It is concise without redundant explanations, though the structure is minimal and lacks an explicit overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description offers almost no detail about the contents of the returned DataFrame. With no output schema, the agent is left without information about columns, data formatting, or any limitations, making it insufficient for non-trivial use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is trivially 100%. The baseline for 0-param tools is 4, and there is no need for the description to explain parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '东方财富-ETF 实时行情' clearly identifies the resource (ETF) and data source (East Money) and indicates real-time quotes. It is concise and specific, though it lacks an explicit verb like 'fetch' or 'list', which is typical for data-retrieval 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/5Does 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 scenarios where this tool is preferred over sibling tools like fund_lof_spot_em or fund_etf_spot_ths.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to restate safety. It adds the source URL and DataFrame return type, but lacks details on date format, pagination, or rate limits. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact and well-structured, with a title, source URL, and parameter/return docs. It is front-loaded with the essential purpose and does not include filler, though the URL could be seen as extra detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description covers source, return type, and parameter meaning. However, it omits date format conventions and behavior when date is empty, leaving some ambiguity for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for 'date', and the description only gives ':param date: 查询日期' (query date) and type string. It lacks format examples (e.g., YYYYMMDD vs YYYY-MM-DD), default behavior, or whether an empty date means today, providing minimal semantic compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as fetching ETF real-time quotes from 同花顺 (THS), with a source URL and return type. It distinguishes from sibling ETF tools by naming THS and ETF spot, though the verb is implied rather than 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention exclusions, preferred contexts, or sibling tools that might be more appropriate for related queries.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the data source is East Money's fund manager page and returns a DataFrame, which provides some context, but it does not disclose additional behavioral traits like pagination, rate limits, or data coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, consisting of a title, a URL, and return-type annotations. It is not verbose, but it lacks a coherent sentence structure and under-specifies the tool's function beyond a label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list retrieval, the description is minimally adequate, but it does not describe the DataFrame columns, the scope of 'all' managers, or any filtering limitations. The absence of an output schema increases the need for such details, which are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to document parameters, and it does not conflict with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '天天基金网-基金数据-基金经理大全' (East Money fund manager list) and specifies a return type of pandas.DataFrame, but it lacks an explicit verb like 'get' or 'list'. It is clear the tool retrieves a fund manager directory, but the description reads more like a title than a functional statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative fund-related tools such as fund_aum_em or fund_cf_em. No exclusions or preferred contexts are mentioned, leaving the agent to infer the tool's 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas DataFrame), but does not disclose additional behavioral traits such as data coverage, potential errors, or rate limits. This is adequate given the annotations 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a title line, URL, and parameter/return documentation. It is concise but not front-loaded in a natural prose format. The title line somewhat duplicates the tool name, but the parameter and return details are useful and efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and strong annotations, the description is mostly complete. However, it does not differentiate from sibling fee-related tools, nor does it describe the columns or content of the returned DataFrame beyond '期货手续费数据'. The default date value is also unexplained, though it is present in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'date' parameter (0% coverage), but the description compensates by specifying the format (YYYYMMDD) and providing an example ('20250213'). This gives the agent clear guidance on constructing valid input, which is essential for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides futures fee data from Jin10 Finance (金十财经-期货手续费) and includes a URL, but it lacks a clear action verb like 'get' or 'list'. It does indicate the resource and data type, but does not distinguish itself from similar sibling tools like futures_fees_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/5Does 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 such as futures_fees_info or futures_comm_info. The description only provides parameter format and return type, leaving the agent without context for choosing this tool among its many siblings.
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?
The description adds the available time window and the output structure (symbol_df and long_short_df), which goes beyond the annotations. It also provides sample data to illustrate the return format. There is no contradiction with the read-only, idempotent, and open-world annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated with a large sample output (over 50 lines), while the actual guidance is minimal. The critical information (what, when, parameters) is mixed with huge data tables, making it hard to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does explain the return value (pandas DataFrame with symbol_df and long_short_df) and provides sample data, which is helpful given the lack of an output schema. However, the parameter descriptions are inadequate, and it doesn't clarify the exact date format or handling of out-of-range dates. For a simple tool, this is middling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must clarify parameters. It lists 'url: 网址' and 'date: 中文名称', but the latter is vague and likely erroneous ('Chinese name' instead of 'date'). The date format is only inferable from the sample output, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource ('净持仓分布' = net position distribution) and indicates this is a data retrieval function for that specific dataset from Qihuo Kechacha. The specific resource is named, but it does not explicitly differentiate from sibling tools like get_qhkc_fund_position or get_qhkc_fund_money_change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives. It mentions an available date range (2016-10-10 to 2019-09-30) which acts as a constraint, but there is no explicit recommendation, exclusion, or comparison with 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?
Annotations already provide strong safety signals (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds the source URL and return type, but no additional behavioral context such as staleness of the mapping, caching, or potential differences from other mapping tools. It does not contradict the annotations, but it adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the title, a reference URL, and the return annotation (:return: and :rtype:). Every line provides useful information without waste. The structure is clean and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is minimal but somewhat adequate—it tells the agent that the tool returns a DataFrame mapping names to codes for global indices. However, it does not specify the exact columns or how the mapping may be structured, and it lacks any contextual notes on when this mapping would be needed or how it differs from other mapping tables in the sibling set. It is complete enough to invoke correctly but leaves room for uncertainty about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so there are no parameter semantics to explain. The baseline for 0 parameters is 4, and the description does not need to compensate. It also does not introduce any confusion about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a '名称代码映射表' (name/code mapping table) for Sina Finance Global Markets, and explicitly notes the return type is a pandas DataFrame with the URL as a reference. This clearly identifies the resource and function, though the verb is implicit rather than explicit. It distinguishes from sibling index tools that provide historical or spot data by being a mapping table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives like index_global_hist_em or index_global_spot_em, nor any prerequisites or exclusions. It only describes what the tool returns, leaving the agent without context for selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to cover safety. It does add the return type (pandas.DataFrame) and the source URL, which are useful, but it doesn't disclose any behavioral traits like date range limits, pagination, or data granularity beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, URL, param list, and return type; every line serves a purpose and there is no fluff. It is front-loaded with the identifying title, making it easy to scan, though the URL is long and not strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple historical data retrieval with two params and no output schema, the description gives the return type and param semantics but omits details like valid period values, output columns, and any data coverage limitations. Given the large sibling set, it also lacks positioning guidance, leaving the agent to guess when to choose this tool over similar ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides basic param meanings (symbol = 基金指数代码, period = 周期) and a concrete example URL with code=807100, giving more than the schema's bare names. However, it doesn't specify allowed period values (e.g., day/week/month), and the '周期' description is too vague to fully compensate for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching historical quotes for Shenwan fund indices (申万宏源研究-申万指数-指数发布-基金指数-历史行情), with a source URL and param docs. It distinguishes from siblings like index_hist_sw by focusing specifically on fund indices, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance on when to use this tool versus alternatives such as index_hist_sw or index_realtime_sw. No exclusions, prerequisites, or comparative hints are provided, leaving the agent to infer usage from the name alone.
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 already disclose read-only and idempotent behavior, so the description adds the source URL and return type. However, the `:return:` line states '配额内' (quota inside) while the title and tool name indicate '配额外' (quota extra), creating ambiguity about the data content. No details about columns, time range, or data granularity are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (a title, URL, and docstring), but the structure is loose—the URL sits between the title and return tags, and the return line contains a typo ('配额内') that could confuse. Still, it is not verbose or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description should clarify what the returned DataFrame contains and how to interpret the index. The contradictory return line ('配额内' vs '配额外') and lack of any description of the data schema make it incomplete. Annotations provide safety but not content details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the empty schema is trivially complete. The description's docstring mentions the return type (pandas.DataFrame) but no parameter details are needed. Baseline 4 applies for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('配额外进口糖估算指数' – extra-quota imported sugar estimated index) and provides a source URL, with docstring return tags indicating it returns a pandas DataFrame. This distinguishes it from the sibling 'index_inner_quote_sugar_msweet' (配额内), though the action verb (fetch/retrieve) is implied rather than 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/5Does 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 such as index_inner_quote_sugar_msweet. The description offers no contextual hints about selection criteria, exclusions, or use cases.
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 already declare read-only and idempotent behavior, and the description adds only the source URL and return type. It does not disclose data scope, columns, or any other behavioral details beyond what annotations already cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the title, followed by a useful URL and return type. It is appropriately sized for a zero-parameter tool, though it omits some useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify the shape of the returned DataFrame. It only states 'bond issuance' without detailing columns, date range, or data granularity, leaving significant ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The description correctly implies no inputs are needed, and the schema confirms this with 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Chinese bond issuance data from chinamoney.com.cn, with a return type of pandas.DataFrame. However, it lacks an explicit verb like 'fetch' or 'query' and does not differentiate from sibling bond-related 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/5Does 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 only supplies a source URL and return type, with no exclusions or references to other 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, so the agent knows it's a safe read. The description adds the fact that it returns a pandas.DataFrame, which is useful. However, no additional behavioral details like rate limits, pagination, or data source quirks are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (4 lines) and front-loads the purpose. However, it mixes Chinese and English with some redundancy (e.g., '票房票房' typo) and is somewhat cryptic for non-Chinese speakers. It earns its place but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains, but it only says '年度首周票房'. The parameter format is under-specified, and there's no mention of what years are supported or whether the date should be the exact date of the first week.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description carries the burden. It mentions ':param date: 当前日期所在年度的年度首周票房票房数据' (data for the year of the current date), which gives some meaning but is vague about format. The example default '20201018' suggests a date string but doesn't clarify the expected format completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving annual first-week box office data from a specific URL, with a specific parameter 'date' and return type. It distinguishes from siblings by mentioning '年度首周票房' (yearly first-week box office), which separates it from other movie_boxoffice_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by showing the date parameter and return type, but doesn't explicitly state when to use this vs. other movie box office tools. It provides minimal context: the date should be the current date's year for that year's first-week data, but no exclusions or alternatives are mentioned.
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?
The annotations already indicate readOnly, non-destructive, idempotent, and openWorld attributes. The description adds only the return type (pandas.DataFrame) and a URL, but no additional behavioral nuances such as data freshness, pagination, or specific columns. It does not contradict the annotations but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of a Chinese title, a URL, and a return type. It is front-loaded and efficient, with no unnecessary words. However, the URL is potentially misleading and could be omitted or corrected, but overall the structure is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should provide more detail about the returned DataFrame's columns or content. It only says '当日合约' (current day contracts) without specifics. The URL inconsistency further undermines completeness, leaving an agent unsure what data to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema already fully describes the interface. With no parameters, the description has nothing to explain, and a baseline score of 4 is appropriate since there is no need for compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns '深圳期权当日合约' (Shenzhen options current day contracts) as a pandas DataFrame, and provides a source URL. However, the URL points to sse.org.cn (Shanghai Stock Exchange), which contradicts the tool name 'szse' and the title '深圳证券交易所', creating confusion about the actual data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as option_current_day_sse or other option data tools. It only states what it returns without any contextual use cases, exclusions, or recommendations.
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 already establish the tool as read-only, idempotent, and non-destructive. The description adds only the return type (pandas.DataFrame) but no behavioral context such as data source, potential latency, or error conditions. It does not contradict the annotations, but it also does not add meaningful behavioral transparency beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is appropriate for a no-parameter tool, but it contains redundancy: the :return line repeats exactly the same phrase as the main description. This wastes a line and could be streamlined. It would be better to remove the repetition or add additional useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool returning a simple list, the description gives the essential information: it returns commodity option codes and names as a DataFrame. However, it omits any details about the data source, update frequency, or column names, and does not clarify whether it covers all commodity exchanges or a specific one. Given the simplicity, it is minimally adequate but lacks finish.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameters to describe, and the schema coverage is complete (100% coverage with an empty schema). The description does not need to compensate for any parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves commodity option variety codes and names (获取商品期权品种代码和名称). It provides a specific verb and resource, making the primary purpose unambiguous. However, it does not explicitly distinguish from similar sibling tools like option_comm_symbol, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention any preconditions, exclusions, or scenarios where another tool would be more appropriate. The description simply restates the output without 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?
The description adds no behavioral detail beyond what annotations already state. Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description only repeats that data is historical and returns a DataFrame, with no mention of data ranges, pagination, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a compact docstring with a URL, parameter list, and return type. The symbol list is necessary and not padded, though the URL line could be considered redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fails to explain what fields the historical data contains, the date range covered, or whether it returns full history. For a data-returning tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, but the description lists 17 valid symbol values and directs users to a helper function for the full symbol table. This adds significant meaning beyond the schema's simple default and covers parameter usage well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool retrieves historical data for Shanghai Gold Exchange spot products, and provides the source URL and a list of supported symbols. However, it does not explicitly differentiate itself from sibling tools like spot_quotations_sge, instead relying on the word 'history' in the name and 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/5Does 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 only related reference is to ak.spot_symbol_table_sge() for obtaining valid symbols, which addresses parameter selection, not tool selection or situational usage.
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 already convey read-only, idempotent, and non-destructive behavior. The description adds the return type (pandas.DataFrame) and a source URL, which provides some context beyond annotations. However, it does not disclose any edge cases, date format expectations, or other behavioral nuances that would be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured with a clear docstring format (params and return type). It includes a useful URL and does not contain excessive filler. The repetition of '指数数据' is minor, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data-fetching tool with no output schema, the description covers the essential parameters and return type, but it lacks context about the meaning of the returned index data, expected date formats, and how the symbol parameter interacts with the URL. The defaults provide some hints, but the description still feels incomplete for an agent without domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides per-parameter docs, but they are minimal: start_date is '开始时间' (start time), end_date is '结束时间' (end time), and symbol is '指数数据' (index data), which is tautological and does not clarify that symbol is the concept board name (as implied by the default '阿里巴巴概念'). It also fails to specify the date format, though the schema defaults suggest YYYYMMDD. With schema description coverage at 0%, the description does not adequately compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: 同花顺-板块-概念板块-指数数据 (THS concept board index data), and includes a specific URL. It distinguishes from siblings by specifying '指数数据' (index data), distinguishing it from other concept board tools like stock_board_concept_info_ths or stock_board_concept_hist_em. However, it lacks an explicit verb like 'get' or 'retrieve', so it reads more like a title than an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No mention of prerequisites, alternatives, or scenarios where this is preferred. The description only gives the source and parameters, leaving the agent to infer usage from the name and schema.
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 already cover safety with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context such as side effects, rate limits, data scope constraints, or output format details beyond stating the return type as pandas.DataFrame. It does not contradict the annotations, but it contributes no extra behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, but the title '东方财富-美股-财务分析-主要指标' is repeated several times (first line, return line, and implicitly in the URL), which is slightly redundant. Still, it is front-loaded with the title and concise enough, with no extraneous filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description merely says the return is a pandas.DataFrame of '主要指标' without specifying which indicators, column names, time periods, or data granularity. For an agent to correctly interpret results, this is insufficient, especially given the wealth of related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It defines symbol as 股票代码 (stock code) and explicitly enumerates indicator choices as {'年报', '单季报', '累计季报'}, which is valuable beyond the bare schema. However, it does not explain the meaning of these choices or provide symbol format examples, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as Eastmoney US stock financial analysis main indicators via the title '东方财富-美股-财务分析-主要指标'. It clearly distinguishes from HK or A-share counterparts by specifying 美股 (US stocks), but lacks an explicit action verb like 'Get' or 'Retrieve', making it more of a noun-phrase label than a full descriptive sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_financial_hk_analysis_indicator_em or stock_financial_analysis_indicator. There are no exclusions, prerequisites, or contextual hints about appropriate use cases.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds minimal behavioral context: it lists the period choices (即时, 3日排行, etc.) and the source URL, but does not disclose any limitations, data update frequency, or other behavioral traits beyond what annotations capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but structured as a raw docstring with a long and noisy URL containing tracking parameters. The title and return type are clearly present, but the format is not optimized for agent consumption and the URL is likely extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the description covers the basic purpose and parameter choices. However, it does not explain the structure of the returned DataFrame or how this tool fits with similar fund-flow tools, leaving some ambiguity for an agent in a large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a generic string parameter with a default. The description compensates for the 0% schema coverage by enumerating the valid choices (即时, 3日排行, 5日排行, 10日排行, 20日排行), giving the agent the essential semantics needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a THS (同花顺) data center tool for concept fund flow (概念资金流), specifying the resource and the return type (pandas.DataFrame). It distinguishes from siblings like stock_fund_flow_individual and stock_fund_flow_industry by explicitly naming 'concept' as the scope, though it lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided for when to use this tool versus alternatives. The name and title imply usage for concept-level fund flow, but there are no stated exclusions or comparisons to the many sibling fund-flow 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, which covers the safety profile. The description adds the data source URL and states that the return is a pandas DataFrame, but discloses no additional behavioral traits such as pagination, data coverage, or update frequency. Given the strong annotation coverage, this is adequate but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact, but it includes a long 100+ character URL and a title line that merely repeats the tool name. The docstring format is standard and front-loaded with the title, but the URL adds noise without contributing essential information, making the structure somewhat cluttered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter data retrieval tool, the description provides the source, parameter meaning, and return type. However, without an output schema, it does not detail the DataFrame columns or underlying data fields, and no edge cases or formatting requirements are mentioned. The read-only annotations help, but the description could be richer to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description explicitly defines 'symbol' as a stock code with type str, and the example URL includes code=03900. This compensates for the missing schema description. However, it does not specify format constraints (e.g., 5-digit leading zeros for HK stocks), so it is not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's first line '东方财富-港股-核心必读-分红派息' is essentially a title that restates the tool name without an explicit action verb like 'retrieve' or 'query'. It identifies the resource (HK dividend payout data from East Money) and the return type, but does not clearly state what the tool does in a functional sentence or distinguish it from sibling HK dividend 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/5Does 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, no exclusions, prerequisites, or context. The description only gives a source URL and a parameter definition, so an agent cannot decide between this and other dividend-related tools like stock_hk_fhpx_detail_ths or stock_history_dividend.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds a return type (pandas.DataFrame) and source URL, which is useful context beyond the annotations. However, it does not disclose any additional behavioral details such as data scope, real-time nature, or potential quirks. It is adequate but not rich, fitting the baseline for a safe read-only operation with good annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, containing only the title, URL, and return type in a clear docstring format. Every element earns its place, and there is no superfluous information. It is brief but effectively structured for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema) and strong annotations, the description is minimally viable but leaves gaps. It explains the return type but not the nature of the news content (e.g., market updates, company announcements) or any temporal scope. It is sufficient for a simple news feed, but richer context would help differentiate it from siblings and clarify expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100%) and there are no parameter semantics to clarify. Per the rubric, a baseline of 4 applies for tools with no parameters, as the description cannot add parameter detail where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (富途牛牛/ Futu news) and provides a URL and return type, but it lacks a clear verb like 'fetch' or 'list.' The resource is evident, but the action is implied rather than stated. It does distinguish from siblings by the source (Futu), but the wording is a noun phrase rather than a directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. With many sibling news tools (e.g., stock_info_global_em, stock_info_global_sina), the description gives no context on why one would choose Futu news over others, nor any exclusions or prerequisite conditions.
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 already convey readOnly, openWorld, idempotent, and non-destructive behavior. The description adds the return type (pandas.DataFrame) and the source URL, which is useful context beyond annotations, but it does not disclose any additional behavioral traits such as pagination, rate limits, or date range constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a clear docstring structure with source URL, params, and return type. It is appropriately sized with no fluff, though the first line duplicates the title annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only data retrieval tool with strong annotations, the description is minimally adequate. It provides source, return type, and parameter names, but lacks usage context and explicit date format guidance. It is not as rich as tools with detailed behavioral or situational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, but it only restates the names in Chinese ('开始日期', '结束日期') without specifying format, requiredness, or constraints. The defaults show YYYYMMDD format, but this is not explicitly stated in the description, leaving the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific data resource: '东方财富网-数据中心-龙虎榜单-每日活跃营业部' (East Money Data Center - Dragon Tiger List - Daily Active Business Departments), and the return type 'pandas.DataFrame' clarifies it retrieves this data. It distinguishes from sibling tools like stock_lhb_yybph_em or stock_lhb_yyb_detail_em by naming the specific daily active department scope, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are any prerequisites or exclusions mentioned. The description only states what the data is, not the context in which an agent should select it.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds only that it returns a pandas.DataFrame, but does not disclose any additional behavioral traits such as data scope, freshness, pagination, or network dependencies. For a read-only data retrieval tool, the description is minimal and provides little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no unnecessary words. It includes the source URL and return type in a compact format. While it could be more structured (e.g., with headers), the brevity is appropriate for such a simple tool, and every line provides some informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must clarify what data is returned. It only says '新股过会' (IPO approval) and the return type, without describing columns, examples, or the nature of the data. This is inadequate for an agent to understand the tool's output or to choose it over closely related tools. The absence of any details beyond the label makes the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. According to the rubric, a zero-parameter tool gets a baseline of 4, and the description correctly does not attempt to explain nonexistent parameters. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool fetches new stock data related to '新股过会' (IPO approval) from cninfo's data center, with a source URL. This gives a specific resource and a clear domain (new stock listings passing review), distinguishing it from sibling tools like stock_new_ipo_cninfo or stock_ipo_review_em. However, it's in Chinese and somewhat terse, lacking an explicit verb like 'get' or 'return', though the return type is mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools such as stock_new_ipo_cninfo or stock_ipo_summary_cninfo. The description merely labels the dataset and provides a URL; it does not explain the specific use case or any exclusions. This leaves the agent to infer from the name alone, which is insufficient given many similar 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description needn't cover safety. It adds a source URL and return type, but it does not clarify symbol prefix expectations (URL shows sh600000 while schema default is 600000) or what the DataFrame contains. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a clear docstring structure: title, URL, params, and return. The source URL adds provenance even if slightly cluttered. No wasted prose, though the title repeats the annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 states that a DataFrame is returned and identifies the data category, but it does not specify the release queue content, date range, or how it differs from sibling versions. It is minimally sufficient but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must fully explain the parameter. It only says ':param symbol: 股票代码', which essentially restates the property name, and does not clarify whether the exchange prefix is required or what data fields are returned. The URL example with sh600000 conflicts with the default 600000 without explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning Sina Finance restricted-share release (限售解禁) data for a stock code, with a source URL and return type. It is specific about the resource and action, but it does not differentiate from sibling tools like stock_restricted_release_queue_em or stock_restricted_release_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides no exclusions, context, or alternative tool names, which is a significant gap given the many sibling restricted-release tools. Usage is only implied as a data retrieval 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return type 'pandas.DataFrame' and the data field '结算汇兑比率', but does not disclose any additional behavioral context such as update frequency, date coverage, or source limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three lines) and includes a source URL and return type, but the first line duplicates the title provided in annotations. While not verbose, the redundancy means not every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only data tool, the description provides a source URL, data content, and return type. However, it does not explain what the settlement exchange ratio represents or how it differs from the reference exchange rate, leaving some ambiguity for an agent comparing sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the rubric, a baseline of 4 applies since there are no parameter semantics to document, and the description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource as '沪港通-港股通信息披露-结算汇兑' (SSE Stock Connect settlement exchange) and specifies a return value of '结算汇兑比率' (settlement exchange ratio). The tool name clearly indicates SSE, distinguishing it from SZSE siblings, though it lacks an explicit imperative verb like 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. Sibling tools such as stock_sgt_reference_exchange_rate_sse and stock_sgt_settlement_exchange_rate_szse are not mentioned, and the description does not explain how this tool differs from them.
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 already declare readOnly, idempotent, and non-destructive behavior. The description adds a source URL and return type (pandas.DataFrame), providing some context, but doesn't mention data freshness, scraping limits, or other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is compact, containing a title, URL, param, and return lines. It is well-structured but the title and return lines are redundant, and the purpose is stated only implicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the return type and a source URL, but no column details or data structure. For a DataFrame-returning tool, the agent cannot infer what fields are included, making the description incomplete for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes ':param symbol: 股票代码' (stock code), which minimally clarifies the parameter beyond the schema's type/string. However, it lacks format details, accepted exchange values, or examples beyond the default '688981' already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (同花顺/THS) and topic (股东持股变动/shareholder shareholding changes) with a URL. However, it lacks an explicit verb and does not differentiate from sibling tools like stock_share_change_cninfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites. The description only restates the tool's scope without contextualizing its use.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), but does not disclose potential pagination, rate limits, or date format validation. With strong annotations, the added behavioral context is minimal but not contradictory, making a score of 3 appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing only a title line, a URL, and docstring-style param/return annotations. It is structured and scannable, with no redundant filler. It loses one point because the title is repeated verbatim in the annotations, adding slight duplication without new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only data retrieval tool, the description provides the essential elements: data source, param purpose, and return type. However, the returned DataFrame content is only described as '个股商誉减值明细' with no column details or examples, and there is no context on how to determine valid date values. Given the lack of an output schema and the presence of closely related sibling tools, the description leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'date' with a default but no description, and schema coverage is 0%. The description says '参考网站指定的数据日期' (refer to the data date specified on the website), which gives vague meaning: it is the report date. However, it does not specify the expected format (e.g., YYYYMMDD) beyond the default '20240630', nor does it explain how dates map to available periods. This is minimally helpful but insufficient for an agent to confidently construct the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns '个股商誉减值明细' (individual stock goodwill impairment details) from EastMoney's data center, with a direct source URL. It is unambiguous about the resource being queried, though it lacks an explicit verb like 'get' or 'fetch'—the title and return statement imply retrieval. It does not distinguish this from closely related sibling tools such as stock_sy_hy_em or stock_sy_profile_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like stock_sy_em, stock_sy_hy_em, or stock_sy_yq_em. There is no mention of prerequisites, scenarios, or when not to use it. The only hint is the source URL, but that does not help an agent choose among the many similar goodwill-related 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame) but doesn't disclose pagination, rate limits, or output details. This is minimal but not redundant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with source URL, parameter, and return type. It is efficient and has no waste, though the title line repeats the source rather than front-loading the function's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch tool, the description provides source, parameter, and return type, with annotations covering safety. However, no output schema exists, and the description doesn't describe the returned columns or any filtering behavior, leaving some ambiguity about the data's structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only says '参考网站指定的数据日期' (refer to the website's specified date), which is vague and doesn't explain the expected format (e.g., YYYYMMDD) beyond the default. The description adds little meaningful semantics over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches '商誉减值预期明细' (goodwill impairment expectation details) from East Money's data center, with a specific URL. This is a specific verb+resource, but it doesn't explicitly distinguish it from sibling tools like stock_sy_em, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites. The only usage hint is the date parameter, which is implied rather than explicitly contextualized.
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?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the return type (pandas DataFrame) but does not disclose additional behavioral traits such as data freshness, rate limits, or pagination behavior. It does not contradict annotations but contributes little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not optimally structured. It repeats the same Chinese phrase in the main text and in the return field, and includes a long URL that may not be essential. The key information is front-loaded but there is some redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description should explain what the returned DataFrame contains. It only states the return type, not the columns or data structure. However, for a simple real-time quote tool, this may be sufficient for basic selection and invocation, but not for full interpretation of the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are zero parameters, the schema is trivially fully covered. The baseline for 0-parameter tools is 4, and the description adds no parameter-specific information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '腾讯财经-港股-AH-实时行情' which identifies the tool as providing real-time AH market quotes from Tencent Finance, and the function name 'spot' reinforces this. However, it does not distinguish this tool from sibling tool stock_zh_ah_spot_em, which likely offers similar data from a different source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to select this tool over alternatives. It only includes a URL and a return type; there is no mention of use cases, exclusions, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the exact source URL and the return type (pandas DataFrame), but does not disclose potential limitations such as valid date formats or that non-trading days may produce empty results. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring structure with purpose, URL, parameter, and return type. It is concise with no filler, though the Chinese docstring style may not be optimally front-loaded for an English-speaking agent, and it starts with a resource name rather than an imperative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with no output schema, the description provides the essential data source, parameter, and return type. However, it lacks detail on the DataFrame structure and date format, and does not clarify how this tool relates to sibling limit-up pool tools, making it minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single date parameter with type string and default, but no schema description. The description repeats '交易日' (trading day) and type str, adding only the concept of a trading day without specifying the date format (e.g., YYYYMMDD) or any constraints, leaving the agent to infer from the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact data source (Eastmoney limit-up board center) and the specific pool ('炸板股池' broken board pool) with a URL, and states it returns a pandas DataFrame. However, it lacks an explicit verb like 'get' or 'fetch' and does not differentiate from sibling tools such as stock_zt_pool_em, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a date parameter indicating that it queries data for a specific trading day, but offers no guidance on when to use this tool versus sibling limit-up pool tools like stock_zt_pool_em or stock_zt_pool_strong_em. No exclusions or alternatives 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that it returns a pandas DataFrame and references a specific data source URL, plus a caution about input format. However, it does not disclose timezone handling, supported city scope, or data availability nuances. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a title, source URL, parameter definitions, and return type. It is reasonably concise and front-loaded with the core title. The URL occupies a line but adds useful source context. No unnecessary filler, though the URL could be seen as extra.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description provides date format, city examples, and return type. However, it lacks an explicit list of supported cities, a clear city format specification, and any note about the data being China-specific. This leaves the city parameter ambiguous and could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It clearly specifies date format with example '20200428', but city format is ambiguous: description examples use Chinese ('北京', '上海') while the schema default is pinyin ('beijing'). The warning '注意输入的格式' does not clarify which format is expected. No list of valid cities or enums is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it returns daily sunrise/sunset data for a specified date and city, with a title '每日日出日落数据' and an explicit return statement. It distinguishes from the sibling sunrise_monthly by specifying '每日' (daily). However, it lacks a strong action verb like 'fetch' or 'retrieve', and the first line is a noun phrase rather than a full sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sunrise_monthly or any other related tools, nor any context on suitable use cases. It only covers parameter formats, not usage scenarios.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the return is a single pandas DataFrame, which is useful context about the output format. It does not add deeper behavioral details like pagination or content specifics, but given the strong annotated safety profile, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, containing the title, a URL, and return type information. However, the raw URL is a large block that disrupts readability and does not directly support tool invocation. The structure is minimally acceptable but could be improved by placing the URL on a separate line or integrating it as a reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter schema, the description is the sole source of information about what the tool returns. It states 'FF多因子模型单一表格' and 'pandas.DataFrame' but does not explain what factors are included, the table's columns, or any other relevant details. The URL hints at the data source but does not sufficiently describe the actual output structure. This is incomplete for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there are no parameter semantics to elaborate. Baseline for zero params is 4, and the description does not need to compensate for any missing parameter documentation. The description's mention of a single table and DataFrame provides some output context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the FF multi-factor model and states that it returns a single table, which implies a retrieval operation. The inclusion of the Ken French data library URL adds context. However, it does not explicitly differentiate from sibling tools or state a verb like 'get', so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives. It neither mentions exclusions nor suggests similar tools like article_epu_index. Usage is only implied by the name and the content, which is insufficient for an agent to decide between many article_* 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?
Annotations already declare read-only and non-destructive behavior, so the safety profile is covered. The description adds the return type (pandas DataFrame) but discloses no other behavioral traits such as data freshness, limitations, error handling, or assumptions about the market identifier prefix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes essential components: a clear title, sample URL, parameter definition, and return type. The URL might be slightly redundant but adds a concrete example, and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the return type and parameter format adequately. However, it lacks details about the contents of the returned DataFrame, valid market prefixes, or any usage guidance, leaving some gaps for a fully informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the symbol parameter, so the description compensates well by explaining it as a convertible bond code with market identifier and providing a concrete default and example URL. This gives the agent the context needed to format the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (convertible bonds from Sina Finance) and the action (retrieve detail/profile information), supported by an example URL. It does not explicitly mention an alternative or contrast with sibling tools, but the name and content together make the purpose 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/5Does 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 other bond-related tools. The description only states what it does and the parameter, without any use-case context or comparison to 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?
Annotations already declare this as a safe read-only, idempotent operation, so the bar for additional behavioral disclosure is lower. The description adds the data source URL and return type but does not disclose behavioral traits like date range handling, pagination, rate limits, or whether the returned data is a snapshot. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a clear title-like path, a URL, and standard parameter documentation blocks. It is not overly verbose, and each element serves a purpose, though the URL could be considered extraneous for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple two-parameter tool has no output schema and relies on the description to convey essential usage context. While the description identifies the data source and general purpose, it omits critical details such as the date format expectation and any note about the date range's inclusivity or exclusivity, leaving an agent with incomplete information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. It provides Chinese labels for start_date ('开始统计时间') and end_date ('结束统计数据'), which adds some semantic value beyond the raw schema. However, it does not specify the required date format (e.g., YYYYMMDD), despite defaults suggesting a numeric format, leaving room for user error.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource as '国债发行' (treasury bond issuance) from Cninfo's data center, which clearly identifies the data domain. The name and title further confirm the tool's purpose, though the description lacks an explicit verb like 'retrieve' or 'list'. It differentiates from siblings by the 'treasury' qualifier, but does not explicitly contrast with other issue types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description's path and the tool name, indicating this is for treasury bond issuance data. However, there is no explicit guidance on when to use this tool versus sibling tools like bond_corporate_issue_cninfo or bond_local_government_issue_cninfo, nor any mention of 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no behavioral traits beyond that, such as error handling, rate limits, or data source quirks. It does not contradict annotations, and the read-only nature is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with URL, title, parameters, and return type. It is well-structured with :param tags and not overly verbose, though the URL placement at the top is somewhat noisy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only says '可转债详情' (details), which is vague about the actual DataFrame structure and columns. Given the indicator parameter changes the returned data, this is a significant gap. The description also fails to clarify how this tool differs from the many convertible bond siblings, so an agent may struggle to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by providing Chinese names for both parameters and explicitly listing the valid indicator choices. However, it doesn't explain what each indicator value returns or provide format requirements for the symbol beyond an example default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving convertible bond details (可转债详情) from East Money, with the URL indicating the specific source. It's clear about the resource but lacks an explicit verb and does not differentiate from similar sibling tools like bond_zh_cov_info_ths in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling bond tools. It does not state prerequisites, exclusions, or alternative tools. The indicator choices are listed but no context is given for choosing among the many bond-related functions.
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 already cover the safe read-only, idempotent nature. The description adds the return type (pandas.DataFrame) and source URL, which is helpful context, but does not explain data contents or access constraints. With good annotations, this level is acceptable 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the title and URL, but the :return line is redundant and contains an apparent copy-paste error ('车型大类' instead of '国别细分市场'), which harms clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns a DataFrame, but the description does not adequately specify what data is included, especially given there is no output schema. The vague and erroneous return description leaves an agent without enough information to understand the tool's output fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter semantics to clarify. The baseline for 0 params is 4, and the description does not introduce any parameter-related confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing CPCA country-segment market statistics with a source URL, distinguishing it from sibling car_market_* tools by the explicit '国别' (country). However, the :return line mistakenly mentions '车型大类' (car model category), which introduces some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like car_market_segment_cpca or car_market_fuel_cpca. The intended usage is only implied by the name and title, not explicitly stated.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. However, the description adds no behavioral context beyond annotations—no rate limits, pagination, data source caveats, or side effects. It only mentions the return type and date format, which are not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with title, URL, param, and return sections. It is front-loaded with the main report name. Minor redundancy (repeating '报告') and the URL could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and no output schema. The description names the return type (pandas.DataFrame) and provides a source URL, but does not describe the DataFrame columns or report structure, leaving uncertainty about the exact data returned. While acceptable for a simple report tool, it falls short of fully equipping an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a 'date' property with no description. The description compensates by explicitly defining the param: 'Specific date, e.g., 20230830' and type str, giving a concrete format example that greatly clarifies usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides the CME Bitcoin volume report ('芝加哥商业交易所-比特币成交量报告') and includes a source URL. It names the specific resource (CME Bitcoin volume) and distinguishes it from sibling tools like crypto_bitcoin_hold_report by specifying 'volume', but it lacks an explicit action verb such as 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only includes a parameter docstring and return type, with no mention of use cases, exclusions, or references to related crypto 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds a source URL and return type (pandas.DataFrame), giving some behavioral context. However, it does not disclose what data is fetched, frequency, or any potential side effects beyond what annotations already imply, which is acceptable given the read-only, idempotent nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short, with the key information appearing early: the Chinese title, the source URL, and parameter documentation. The docstring-like format is clear and structured, though the URL line is somewhat extraneous. Overall, it is efficient and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only index tool with one parameter and no output schema, the description provides the parameter choices and return type but does not describe the DataFrame's columns, time range, or data granularity. This is a moderate gap, but the simplicity of the tool and the presence of an explicit symbol enumeration make it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'symbol' with no description or enum. The description explicitly enumerates valid symbol values ('composite', 'shanghai-rotterdam', etc.) and specifies the type as str, providing meaningful information beyond the schema. It does not explain the meaning of each route, but the enumeration is valuable for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Drewry 集装箱指数' which identifies the resource (Drewry Container Index) but lacks an explicit verb like 'retrieve' or 'get'. It is clearer than a pure tautology because it names the specific index, yet it does not differentiate from sibling shipping index tools beyond the tool name. The symbol choices provide some context, but the overall purpose is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative shipping index tools, nor any mention of exclusions or prerequisites. The description only lists symbol options, providing no usage context. An agent would not know why to choose this over, for example, macro_shipping_bdi.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and a source URL, but does not disclose any behavioral details like data range, columns, or potential quirks. With annotations present, this is modest but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, consisting of a title, a URL, and a return type. It is concise and front-loaded, but it is slightly repetitive: the first line and the ':return:' line say the same thing. This minor redundancy prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with rich annotations, the description is minimally sufficient. It states the output is a DataFrame of historical price adjustment info, but provides no details on columns, time period, or data source specifics beyond the URL. Given the simplicity, this is adequate but leaves room for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any parameter semantics. According to the rubric, a 0-parameter tool receives a baseline of 4. The description adds no parameter-related information because there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '汽柴油历史调价信息' (gasoline and diesel historical price adjustment information), which is a clear resource identifier but lacks an explicit action verb like 'get' or 'fetch'. It distinguishes itself from siblings like energy_oil_detail by specifying historical price adjustment data, but this is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of suitable scenarios, exclusions, or related tools such as energy_oil_detail or macro_china_energy_index. The description simply repeats the title and URL without any contextual advice.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a pandas.DataFrame with daily quotes, which is useful, but it does not disclose date format, error behavior, or rate limits. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a one-line title followed by a Python-style docstring. It avoids redundant prose. The URL example adds some value but is not essential, and the parameter lines are efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple historical-data fetch, the description covers the key parameters and return type. Yet it omits usage guidance, date format details, and any differentiation from related sibling tools, making it only partially complete for an agent trying to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides Chinese names and explicit enum choices for period and adjust, plus a return type, which is valuable because the input schema has 0% description coverage and no enum definitions. However, it does not specify the expected date format for start_date and end_date, though the schema defaults imply YYYYMMDD.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is '东方财富-LOF 行情', a noun phrase identifying the data source and instrument but not a clear verb-action statement. The historical aspect is inferred only from the tool name and the date-range parameters, not explicitly stated. It also does not distinguish itself from sibling tools like fund_lof_spot_em or fund_lof_hist_min_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools such as fund_lof_spot_em and fund_lof_hist_min_em exist, but the description does not mention them or offer any selection criteria. It only lists parameters and return type, leaving the agent to infer 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description does not add any additional behavioral traits such as data availability, rate limits, or what the DataFrame contains; it only states it returns a pandas DataFrame of industry allocation, which 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing a title, URL, parameter docs, and return type in five lines. It is front-loaded with the title and no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose, parameters, and return type, but lacks details about the DataFrame's columns, valid year ranges, or when data is available. For a simple retrieval tool with no output schema, this is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description provides ':param symbol: 基金代码' (fund code) and ':param date: 查询年份' (query year), which clarifies the meaning and ensures the agent knows what to pass. Defaults are also present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving industry allocation (行业配置) from the fund's investment portfolio section on EastMoney, with a URL and return type indicating the data. It is distinct from sibling tools like fund_portfolio_hold_em and fund_portfolio_bond_hold_em. However, it lacks an explicit verb like 'get' or 'query', relying on the noun phrase 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no information about when to use this tool compared to other fund portfolio tools (e.g., fund_portfolio_hold_em) or alternative data sources (e.g., fund_report_industry_allocation_cninfo). It only provides parameter docs and return type, with 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the source URL and return type, but no behavioral details such as latency, pagination, or the structure of the returned DataFrame. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repeats '基金评级总汇' multiple times (title, return, and rtype). It is front-loaded with the title and URL, but the repetition is unnecessary. Still, it is compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is minimally sufficient: it names the source and return type. However, it does not describe the columns or content of the DataFrame, and it doesn't clarify the scope (e.g., all funds, all rating agencies) beyond the name. Given the lack of an output schema and the presence of sibling fund rating tools, a bit more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema confirms this. The description provides a return type (DataFrame), which is useful but not parameter-related. Per the baseline for 0-param tools, this scores 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a Chinese navigation path ('天天基金网-基金评级-基金评级总汇') and a URL, with a return line that repeats the tool's name. It indicates the tool returns a summary of fund ratings from Eastmoney, but it doesn't describe what a '基金评级总汇' contains or how it differs from related tools like fund_rating_ja/sh/zs. The verb is implicit ('returns'), and the resource is identifiable via the URL, so it's not entirely tautological, but little value is added beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs. alternatives such as fund_rating_ja, fund_rating_sh, or fund_rating_zs. The description does not mention any exclusions, prerequisites, or preferred use cases.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame) but no additional behavioral context such as rate limits, pagination, or data freshness. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a structured docstring format with title, URL, param, and return sections. However, the URL appears twice (in the title line and in the param description), which is redundant. It is compact but not maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single optional parameter, no output schema, and the description only states that the return is '上海证券评级' (Shanghai Securities rating) as a DataFrame. It does not specify the columns or data granularity, but given the low complexity and the annotations covering safety, this is minimally viable yet leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining the 'date' parameter as '日期' (date) and directing the user to the URL for query date reference. However, it does not explicitly state the expected format (though the default '20230630' implies YYYYMMDD), leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '天天基金网-基金评级-上海证券评级' (Eastmoney fund rating - Shanghai Securities rating) and provides the source URL. While it lacks an explicit verb like 'fetch' or 'get', the intent is unambiguous and it is distinguishable from sibling tools like fund_rating_zs or fund_rating_ja by the 'sh' suffix and Chinese 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/5Does 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 the sibling rating tools (e.g., fund_rating_all, fund_rating_ja, fund_rating_zs). It does not mention alternatives or exclusions, leaving the agent to infer usage solely from the name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the return is a DataFrame of 招商证券评级-混合型 and provides a URL to find the query date. This adds some behavioral context but does not disclose potential scraping behavior, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat repetitive, with the same URL appearing twice. It uses a docstring-like structure with param/return sections, which is organized, but the opening line is a duplicate of the title. There is no clear, front-loaded summary sentence. It is concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description provides the data source, return type (DataFrame of 招商证券评级-混合型), and parameter guidance. However, it does not explicitly state that only hybrid funds are returned, nor describe the DataFrame columns or any limitations. For the simplicity level, it is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It states 'date: 日期' and points to the URL for obtaining a valid query date. The type is given as str and the default '20230331' implies a YYYYMMDD format, but this is not explicitly stated. The description adds minimal meaning beyond the schema, though it at least identifies the parameter's purpose and a source for valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: fund ratings from 天天基金网 (Eastmoney) specifically for 招商证券 (China Merchants Securities). The return type also specifies it covers hybrid funds (混合型). While there is no explicit verb like 'fetch' or 'query', the name and context make the action obvious. It differentiates from sibling rating tools by naming the agency, though it does not explicitly compare 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as fund_rating_all, fund_rating_ja, or fund_rating_sh. No mention of appropriate use cases, prerequisites, or exclusions. The only hint is the URL for obtaining a valid date, which is not usage guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the return is a pandas.DataFrame and that the symbol is a futures symbol, but does not disclose what fields or time periods the 'detail' covers, nor any pagination or error behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a standard docstring format with a brief summary, param, and return sections. It is front-loaded with the summary and contains no filler, though it could benefit from a more descriptive opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with strong annotations, the description is adequate but incomplete. It does not describe the content of the returned 'contract detail' DataFrame or how it differs from related futures tools. There is no output schema and no explanation of coverage (e.g., which foreign exchanges or time ranges). Enough to invoke, but with clear ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a name, type, and default for the symbol parameter with 0% description coverage. The description compensates by explaining that the parameter is a futures symbol and points to the exact function (ak.futures_hq_subscribe_exchange_symbol) where valid symbols can be obtained. This adds meaningful semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'foreign futures contract detail data', which closely mirrors the tool name and title, providing little beyond a noun phrase. It implies the tool returns contract details for a given symbol, but lacks a clear verb or explicit differentiation from sibling tools like futures_foreign_hist or futures_contract_detail. The parameter and return lines add modest clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The only usage hint is that the symbol can be obtained from ak.futures_hq_subscribe_exchange_symbol, which is a prerequisite for the parameter, not a usage guideline. There are no 'when-to-use' or 'when-not-to-use' statements.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds some context beyond annotations: the source URL and that the return is a pandas DataFrame. However, it does not disclose details like data freshness, pagination, or the exact structure of the returned DataFrame. Given annotations cover the key traits, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a clear docstring structure: title, URL, parameters, and return type. Every line serves a purpose and there is no filler text. It is not front-loaded with a user-focused sentence, but it is concise and easy to scan. A 4 reflects good structure within a minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and the description is the only source of parameter meaning, it provides basic completeness: all three params are explained, and the return type is stated as pandas.DataFrame. However, it lacks details about what columns the DataFrame contains, how '成交持仓' is structured, and how this tool relates to the many sibling futures tools. Without this, an agent might not know if it returns daily historical data, current positions, or something else. This is a moderate completeness level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden of explaining parameters. It does this well: symbol is given an explicit choice set ({"成交量", "多单持仓", "空单持仓"}), contract is defined as '期货合约', and date as '查询日期'. It also specifies the return type. While date format and contract syntax are not explicitly detailed, the defaults in the schema (e.g., '20240223', 'OI2501') help. This meaningfully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is primarily a noun phrase '新浪财经-期货-成交持仓' (Sina Finance - Futures - Volume/Open Interest) followed by a URL and parameter docs. It identifies the data source and topic but lacks an explicit verb like 'query' or 'fetch'. The return type 'pandas.DataFrame' implies data retrieval, but the action is not stated directly. It does not distinguish itself from sibling tools beyond the source and data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 are no exclusions, prerequisites, or references to other tools. It only lists parameters and return type, leaving the agent to infer usage context from the tool name and sibling list.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds parameter choices and return type but does not disclose data structure, pagination, or rate limits. This is minimal additional value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with labeled sections for parameters, types, and returns. It is front-loaded with the name and URL, and contains no unnecessary fluff. The structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter and no output schema, the description covers the source, parameter domain, and return type. However, it does not describe the DataFrame columns or the content of the news flashes, leaving some ambiguity about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with a default, but the description lists all allowed values (全部, 要闻, VIP, 财经, 铜, 铝, etc.), which is critical since schema coverage is 0%. This gives an agent explicit guidance on valid inputs, though it does not explain each category in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides the resource name '上海金属网-快讯' and a URL, indicating it is about Shanghai Metal Network news, but lacks an explicit verb like 'fetch' or 'get'. It differentiates from siblings by naming the specific source, but the purpose is implied rather than clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 comparison with other news tools or any prerequisites. The usage context is only implied by the URL and parameter choices.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety behavior. It adds the return type (pandas.DataFrame) and the fact that the data comes from a specific website page, which provides useful context. However, it does not disclose any other behavioral traits such as historical depth or data frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with :param and :return tags. It includes only essential info: title, source URL, parameter meanings, and return type. No fluff or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description covers basic usage but lacks detail on the structure of the returned DataFrame or any edge cases (e.g., what happens if an invalid symbol is given). The source URL provides some context, but overall the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full weight for parameter meaning. It explains that symbol is a futures product (e.g., 铜) and indicator choices are enumerated as {"市场价格", "基差率", "主力基差"}. This is sufficient to understand what each parameter does, though it could provide more detail on valid symbol values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a title and docstring rather than a clear verb phrase. It identifies the resource as a spot-futures chart from 100ppi.com, but does not explicitly state what the tool does (e.g., 'Fetches' or 'Returns'). It is distinguishable from siblings only by the source name, not by a clear action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over the many sibling tools (e.g., futures_spot_price, futures_spot_price_daily). No alternative tools are mentioned, nor are any exclusions stated. The URL is given but does not clarify use cases.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context: units for different commodities (ton, gram, kilogram, barrel) and that delivery/spot volumes are one-way calculated. It also provides a source URL. However, it does not describe return formatting, error behavior, or pagination, so it adds some but not rich 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a lengthy list of commodity units, which is informative but adds bulk. It is structured as a title, URL, numbered list, calculation note, and type hints. However, it lacks a clear imperative purpose statement and is cluttered with details that could be summarized or moved to the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and good annotations, the tool is relatively simple. The description provides useful unit semantics and a note about one-way calculation. However, there is no output schema and the return value is only described as '上海期货交易所期转现', which is vague. The DataFrame columns and row structure are not described, making it incomplete for interpreting the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (date) with no description and coverage is 0%. The docstring's ':param date: 年月' provides a year-month format hint, which is valuable given the bare schema. The default '202312' implies YYYYMM, but the description does not explicitly state the format or give additional examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The first line '上海期货交易所-期转现' clearly identifies the resource (SHFE futures-to-spot) and the exchange, which differentiates it from sibling tools like futures_to_spot_czce and futures_to_spot_dce. However, it lacks an explicit verb such as 'get' or 'retrieve', making it more of a noun phrase than a directive statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 futures_to_spot_czce or futures_to_spot_dce. The only differentiator is the exchange name in the title, and no prerequisites or exclusions 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that the return type is a pandas DataFrame, which is useful but not disclosed elsewhere. It does not describe any quirks about the data (e.g., date range, columns, or source behavior), but with annotations covering side effects, the additional context is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured with a URL, parameter docstring, and return type. It front-loads the main purpose and does not waste words. The format is easy to scan, and every line adds some value, though the URL is cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, the description is fairly complete: it states the data source, how to get the symbol, and the return type. However, it does not describe the DataFrame's columns or the temporal scope of the data, which could matter for an agent deciding whether this tool meets the user's need among many futures alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does explain that symbol can be obtained from match_main_contract or the webpage, and provides an example URL. This adds meaning beyond the bare schema, though it does not explain the symbol format in detail or list valid conventions. The guidance is helpful but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides Chinese futures daily frequency data, which aligns with the tool name, but it lacks an explicit verb (e.g., 'retrieve') and is largely a noun phrase restating the title. It does provide a URL and mentions the return type, giving some clarity, but does not clearly differentiate from similar tools like futures_zh_realtime or futures_zh_minute_sina beyond the 'daily' frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives helpful guidance on how to obtain the symbol parameter via match_main_contract or the web page, which is a form of usage context. However, it does not explicitly state when to prefer this tool over alternatives (e.g., minute or realtime futures tools), nor does it mention any prerequisites or exclusions beyond symbol acquisition.
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 already declare readOnlyHint=true and destructiveHint=false, so the description does not need to cover safety. It adds a performance caveat ('返回数据会变慢') when adjust='1' and explains that adjust affects the return content, which is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a URL and repeats '期货的实时行情数据' in both the first line and the return line. It is compact but has redundancy and unstructured docstring formatting, making it moderately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the return description ('期货的实时行情数据') is vague, offering no column details beyond the adjust note. It does not provide examples or clarify the full range of market values, leaving the agent uncertain about the exact data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains symbol as contract name combination, market='CF' for commodity futures, and adjust='1'/'0' behavior along with the performance tradeoff. This is valuable, though the symbol format remains vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '期货的实时行情数据' (futures real-time market data) and specifies the return type as pandas.DataFrame, indicating a data retrieval function. However, it does not differentiate from sibling tools like futures_zh_realtime or futures_main_sina, and uses a noun phrase rather than an explicit verb+resource construction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides parameter documentation and a source URL, lacking exclusions or comparisons to the many sibling futures 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?
The annotations already declare this as a read-only, idempotent operation. The description adds only the source URL and return type, without behavioral details like network dependency or data freshness; since the safety profile is covered, this is acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes the source URL, then a compact docstring. The structure is adequate though the URL line could be integrated, and it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool this may be borderline, but it leaves out what the DataFrame contains (columns, date format) and does not clarify how this relates to the separate weekly/monthly tools. The lack of an output schema heightens the need for a clearer return specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'symbol' merely as a string with a default, lacking any enum or description. The description compensates by explicitly listing the allowed values {'week', 'month'}, giving the agent the semantics needed to select the appropriate period.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description primarily restates the tool's title, adding that it returns a date sequence from Shenwan Hongyuan weekly/monthly reports. It lacks a clear verb and does not distinguish from sibling tools such as index_analysis_weekly_sw or index_analysis_monthly_sw, leaving the exact operation ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention related sibling tools or any conditions that would make this tool preferable, leaving the agent to infer usage from the name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is clear. The description adds the source URL and return type but no additional behavioral details such as data freshness, limitations, or time-series scope. With annotations covering safety, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, URL, return annotation, and return type. It has no wasted words and is front-loaded. However, it's more a docstring fragment than a coherent description, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description only states that it returns a pandas DataFrame of '基础指数', which is vague and doesn't describe columns or meaning. The tool is simple with no parameters and has annotations for safety, which partially compensates, but the return data is under-described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers the input surface (vacuously). The description provides no parameter-specific semantics, but none are needed. Per baseline for 0 params, this scores 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '基础指数' (basic index) from Caixin Data and includes a source URL, but it lacks a verb specifying the action. The return annotation '基础指数' implies retrieval, but the purpose is not explicitly stated as an operation. It doesn't differentiate from the many sibling index_*_cx 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description gives no indication of when to choose this tool over alternatives like index_ai_cx or index_si_cx. It doesn't mention any prerequisites, frequency, or exclusion criteria, leaving the agent without guidance for selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), but does not disclose details like column structure, pagination, or date handling, so it provides only moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring pattern: title, source URL, params, and return type. It is front-loaded with the data type and includes only necessary lines, though the title is redundant with the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should describe what the returned DataFrame contains (e.g., OHLCV columns), but it only says 'index historical market data.' It also doesn't clarify index code format or date boundaries, making the tool under-specified for a data-fetching function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters; it does give Chinese labels for symbol (指数代码), start_date (开始时间), and end_date (结束时间). Yet it omits format details such as YYYYMMDD (implied by the defaults) and doesn't explain any constraints, leaving ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates that this tool provides historical index market data (指数历史行情数据) and includes a source URL identifying cnindex.com.cn. However, it uses a noun phrase rather than an explicit verb+resource statement, and it does not explicitly distinguish from sibling index history tools like index_global_hist_em or index_detail_hist_cni.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the many sibling index-data tools. It lacks alternatives, exclusions, or contextual prerequisites such as 'use for CNI indices' or 'not for global indices.'
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds little beyond confirming the data is returned as a DataFrame. It does not disclose behavioral traits like data source limitations, rate limits, or column contents beyond the basic return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring, with title, URL, parameter types, and return type in a logical order. Each line contributes value, though the raw URL could be trimmed without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description covers the core function, parameter meanings, and return type. However, it omits details such as the exact columns of the returned DataFrame, whether prices are adjusted, and any limitations of the data source, leaving minor gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well by explaining symbol as index code and period as a choice of {'day','week','month'}. It also provides a URL example with a concrete symbol code, adding useful context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves index historical data ('指数历史数据') for a given symbol and period, with the URL and return type confirming this. It distinguishes from likely siblings like realtime or minute index tools by specifying '历史数据' (historical data), 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 Guidelines2/5Does 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 index_min_sw or index_realtime_sw. The description only documents parameters and return type, with no mention of use cases, exclusions, or preferred contexts.
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?
The description adds minimal behavioral context beyond the annotations: it notes the data source (Chinascope via the research URL) and the return type (pandas DataFrame). Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description does not mention update frequency, time range, columns, or any operational caveats, but it does provide the output format which is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (three lines) and front-loads the index name. The URL and return type are useful, but the duplicate mention of 'A股新闻情绪指数' wastes space and the overall structure is a stub rather than a well-organized explanation. It is concise but minimal, so it earns a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description is incomplete: it only provides the index name and return type, without explaining what the index represents, its market scope (A-share), how it is calculated, or the structure of the returned DataFrame. Given the rich annotations, the description does not need to repeat safety warnings, but it should offer more context to help the agent understand the data and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description correctly reflects this by not discussing any parameters. Since there are no parameters to document, the baseline score of 4 is appropriate. The description does not need to compensate for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a '数库-A股新闻情绪指数' (Chinascope A-share news sentiment index) and states the return type. However, it lacks an explicit verb like 'get' or 'retrieve', and does not differentiate from sibling index tools that may also provide sentiment or index data. The name itself suggests the function, and the Chinese title plus return specification make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 suitable use cases, prerequisites, or compare this to other sentiment indices or index-producing tools. An agent cannot determine whether this is the right tool without additional context.
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 already declare this is read-only, idempotent, and non-destructive, so the description need not repeat those. It adds a source URL and return type (DataFrame), which offers some behavioral context beyond annotations, but it does not disclose data update frequency, rate limits, or column specifics. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but contains redundancy: the first line and the ':return:' line are identical phrases. The URL and ':rtype:' are useful, but the duplication wastes space and could be consolidated for better structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter, read-only nature with good annotations, the description covers the essentials: it states the data type (QVIX intraday for CSI 300 index options), provides a source URL, and specifies the return DataFrame format. It does not detail columns or update schedule, but for a simple tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully complete (100% coverage), and the baseline for 0 params is 4. The description adds no parameter-related details, but it provides context about the data source and return format, which is sufficient for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the tool name restated in Chinese ("中证300股指 期权波动率指数 QVIX-分时"), identifying the resource and frequency but lacking an explicit verb like 'fetch' or 'return'. It does state the return type (pandas.DataFrame) and a source URL, which adds some clarity, but the purpose is more labeled than defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 similar siblings such as index_option_300index_qvix (likely daily) or other index variants. The description only mentions '分时' (intraday) without contrasting it with alternatives, so an agent cannot easily decide between this and closely named 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?
Annotations already cover the safety profile (readOnlyHint, openWorldHint, idempotentHint, destructiveHint). The description adds the data source (JoinQuant) and return type (DataFrame), which is useful but does not disclose additional behavioral traits such as pagination, rate limits, or data freshness. This is consistent with annotations and adds some value, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of the title, a reference URL, and return type annotations. It is compact and free of fluff, but it lacks a clearer structure or a sentence explaining the tool's action. Still, every line serves a purpose, so it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description gives a basic understanding: it returns a DataFrame of index information. However, it does not specify the columns or confirm the exact output structure, and there is no output schema to fill the gap. The URL might provide details, but it is not self-contained. This is adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description does not need to explain parameter behavior. Per the rubric, a zero-parameter tool gets a baseline score of 4, and no deduction is needed since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns an '指数列表' (index list) from JoinQuant, indicating a tool that retrieves a list of index information. This distinguishes it from sibling tools like index_hist_cni (historical data) or index_stock_cons (constituents). However, there is no explicit verb like 'get' or 'list', so it falls short of a fully specific verb+resource+scope description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 any scenarios, prerequisites, exclusions, or alternative tools. The only extra context is a URL to the JoinQuant data dictionary, which is a reference link rather than usage guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds source (East Money) and return type (pandas.DataFrame), but does not mention rate limits, date format quirks, or potential data gaps. This is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the title. The docstring format is standard and includes a URL. No redundant sentences, though the format is more code-oriented than natural language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what columns are returned and the meaning of '行情数据'. It only says the return type is pandas.DataFrame. The tool is a simple historical data fetcher, but the lack of details about date format, data fields, and potential edge cases makes it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with parameter names, types, and Chinese labels: symbol is '指数代码', start/end dates are clearly start and end dates, and period lists valid choices {'daily', 'weekly', 'monthly'}. However, date format (e.g., YYYYMMDD) is not explicitly stated, and the default end_date '22220101' appears anomalous, limiting clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (East Money China stock index) and the nature of the data (market data). The URL adds specificity. However, it does not explicitly state 'retrieve historical data' and does not differentiate from sibling index tools like index_zh_a_hist_min_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that this is for daily/weekly/monthly historical index data, nor does it exclude intraday or spot data. The parameter list implies usage but provides no selection criteria.
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 already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read operation. The description adds the source URL and return type (pandas.DataFrame), which provides some context, but it does not disclose behavioral traits such as data coverage, update frequency, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title and URL, but it repeats the title in the ':return:' line ('央行公布利率决议'), which adds redundancy. It is appropriately sized for a no-parameter tool but could be structured to avoid repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should ideally explain what data is returned, but it only says '央行公布利率决议' (interest rate decision) without fields, examples, or historical coverage. While the simple nature and annotations help, the lack of detail on return structure leaves the agent guessing about the DataFrame contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the baseline, this scores 4 because there is no parameter ambiguity to resolve. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving Canada's central bank interest rate decision from East Money's economic data section (央行公布利率决议), which clearly distinguishes it from sibling bank rate tools for other countries. However, it relies on a noun phrase rather than an explicit verb like 'Get' or 'List', making the intended action slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides only a source URL and return type, with no mention of suitable contexts, prerequisites, or alternative tools. The country is the only implicit differentiator, but no explicit usage direction is given.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and a source URL, which provides some context beyond the annotations, but it does not describe data granularity, potential missing values, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the ':return' line merely repeats the title, which is redundant. The URL is useful, but the structure resembles a raw docstring rather than a polished description, and the redundancy costs a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain the return value in more detail. It only provides the index name and the DataFrame type, but does not describe columns, time range, or whether it is historical or current data. The safe-read annotations help, but the overall context is incomplete for an agent to fully understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. Since there are no parameters to explain, the description does not need to add parameter semantics, and the baseline of 4 for a zero-param tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the agricultural product wholesale price total index, and the included URL provides a unique data series identifier. However, it lacks an explicit verb and does not differentiate from sibling tools like macro_china_agricultural_index, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 neither states the intended use case nor mentions any exclusions or alternative tools, leaving the agent to infer the appropriate context.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description need not repeat these. It adds useful context: the date range (from 2012-01-20 to present) and return type (pandas.DataFrame). However, it does not disclose data granularity, columns, or update frequency beyond what is visible in the name and URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the return phrase '中国年度财新 PMI 数据' appears twice, and the URL is long without explanation. It is not overly verbose, but the repetition and unformatted URL detract from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain the returned DataFrame, but it only states 'pandas.DataFrame' without detailing columns, value meaning, or frequency (beyond the 'yearly' in the name). It also does not clarify the manufacturing vs. services ambiguity. The date range and source URL are helpful, but the overall picture is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the input schema is fully empty. No additional parameter-related information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as China annual Caixin PMI data ('中国年度财新 PMI 数据') and provides a source URL. While it lacks an explicit verb like 'get' or 'fetch', the intent is unambiguous. It does not explicitly differentiate manufacturing from services PMI, but the tool name and URL hint at caixin manufacturing PMI.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this is for Caixin PMI rather than official NBS PMI, nor does it differentiate from similar tools like macro_china_cx_services_pmi_yearly or macro_china_pmi_yearly. No exclusions or alternative recommendations are given.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and a return type, but does not disclose additional behavioral traits such as data frequency, range, or whether it scrapes dynamically. With annotations present, the minimal extra context is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, containing only a URL, a Chinese title, and a return type annotation. It is front-loaded with the source URL and title, and each element serves a purpose. It is appropriately sized for a no-parameter data retrieval tool, though it could benefit from a small amount of explanatory prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description names the specific economic index and identifies the source URL, which helps an agent understand what data is returned. However, there is no output schema and the description does not describe the DataFrame's columns, frequency, or historical coverage. Given the large number of sibling tools, a bit more detail would help disambiguate, but the core purpose is reasonably covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete with 100% coverage. Per the baseline for 0 params, the description need not explain parameter semantics. The absence of parameters is fully clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source via URL and gives a clear Chinese title '中国-企业景气及企业家信心指数' (China Enterprise Prosperity and Entrepreneur Confidence Index), which specifies the content. The return type pandas.DataFrame confirms it is a data retrieval function. However, there is no explicit verb like 'get' or 'fetch', though the title makes the purpose sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 instead of the many other macro_china_* tools. There are no alternatives mentioned, no context for use cases, and no exclusions. An agent is left to infer the tool's niche solely from the title.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds only the source URL and return type, but no additional behavioral context such as network dependencies, data freshness, or output structure. It does not contradict annotations, but also does not add meaningful behavioral insight beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally brief, composed of a title, URL, and return type statement. It is front-loaded with the resource identity and contains no filler. While sparse, it is appropriately concise for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and annotations cover its safety profile, the description is minimally complete. It states the return type (pandas.DataFrame) and the value (航贸运价指数), but does not describe the data's time range, column structure, or any caveats about usage or availability. For a data retrieval tool, this is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description cannot add parameter meaning. Schema coverage is 100% (empty schema), and the description correctly implies no input is required. Per rubric, a 0-param tool receives a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the Sina Finance China macro freight index (航贸运价指数) and states the return type. It is distinguishable from sibling tools by the specific index name, but lacks an explicit verb like 'fetches' or 'returns' to fully articulate the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative macro indicators or freight-related tools. It does not mention any context, prerequisites, or exclusions, leaving the agent without information to differentiate its use cases.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type, which is some context, but it does not disclose what the DataFrame contains, time range, or frequency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured, but it contains redundancy: the title is repeated verbatim in the :return: line. The URL is useful, but the docstring could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a data retrieval tool with no output schema, so the description should explain what the returned DataFrame contains. It only says 'China GDP' and 'DataFrame' without specifying frequency, columns, units, or historical coverage. Given the sibling macro_china_gdp_yearly, the description also fails to clarify how this tool differs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description provides the return type (pandas.DataFrame), which is the only relevant semantic detail. No parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (China GDP) and source (East Money), and specifies it returns a pandas DataFrame. It lacks an explicit verb, but the name and title together make the purpose unambiguous. It does not differentiate from the sibling macro_china_gdp_yearly beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_china_gdp_yearly. There is no mention of use cases, prerequisites, or when not to use it.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the return is a pandas.DataFrame and provides a source URL, which is some useful context. However, it does not disclose details like data frequency, date range, or column structure, so it remains at a baseline level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat redundant: the title is repeated in the annotation, and the ':return:' line essentially restates the title. The URL is useful but the structure is not optimized. It is not as lean as a two-sentence description that adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but there is no output schema. The description only gives a generic label and return type, without explaining what columns, time periods, units, or ranges are included. This is insufficient for an agent to understand what data will be returned and how it might be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. With no parameters to document, a baseline of 4 applies. The description does not need to explain parameter semantics because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific resource: Hong Kong building sale contract transaction amounts from East Money, with a source URL. It implies retrieval and the return type is stated as pandas.DataFrame. While there is no explicit verb like 'get' or 'fetch', the resource and scope are clear, and the name distinguishes it from the sibling macro_china_hk_building_volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context in which this data would be preferable. The description is purely declarative and leaves the agent to infer usage from the name.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a useful detail by specifying the return type as pandas.DataFrame and provides the data source URL, but it does not go beyond that to describe data granularity, update frequency, or any other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with three concise parts: the title, the source URL, and the return type. It avoids unnecessary verbosity, though the first line merely echoes the title, which is slightly redundant. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description provides the essential facts: what data it returns (Hong Kong GDP YoY) and the return format (pandas DataFrame). However, it is minimal—no explanation of the data's columns, the time series nature, or any limitations, which may leave an agent uncertain about the exact structure of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object. According to the baseline for zero parameters, the description does not need to add parameter-level detail, and it correctly omits any. The lack of parameters is clearly communicated through the schema, and the description does not introduce any confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Hong Kong GDP year-over-year data from East Money, and the return type is specified as a pandas DataFrame. However, it lacks an explicit verb like 'fetch' or 'return'—the description is largely a restatement of the title, which itself already provides the same information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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, no description of ideal use cases, and no mention of prerequisites or exclusions. Sibling tools like macro_china_hk_gbp or macro_china_hk_cpi_ratio are not referenced, leaving the agent without any context for selecting this specific 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the data range and source URLs, and states the return type (pandas.DataFrame). It does not disclose additional behaviors like column structure or data frequency, but given the strong annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured, starting with a redundant title phrase, then two URLs on separate lines, and ending with return/rtype lines. It reads like a docstring dump rather than a curated definition. It could be condensed into one or two clear sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the data range, source URLs, and return type, which is useful for a simple no-parameter tool. However, it does not specify what columns or fields the DataFrame contains, nor the data frequency (monthly? quarterly?). Without an output schema, this leaves gaps in understanding the returned data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds nothing about parameters, but none are needed. The schema is empty and coverage is 100%, so no information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a report on China's imports YoY in USD, with a specific data range (19960201-present). It names the resource and metric precisely. However, it does not explicitly differentiate from sibling tools like macro_china_exports_yoy, relying on the name rather than description to distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It provides data range and source URLs but no context about scenarios, prerequisites, or exclusions. For a tool with many macro-related siblings, this is a clear gap.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and a source URL, offering some context beyond annotations. However, it does not disclose any other behavioral traits, such as data range, potential missing data, or request behavior. With annotations covering the main concerns, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing the title, source URL, return value, and return type in a few lines. It is not bloated, but the structure is fragmented (multiple lines without full sentences) and the information is somewhat sparse. Still, every part adds a small piece of context, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what the return looks like. It states the return type is pandas.DataFrame and labels the content as '民航客座率及载运率', but it does not specify columns, date range, or data granularity. For a no-parameter read-only tool, this is adequate but leaves the agent uncertain about the actual data structure. A 3 reflects this acceptable yet incomplete explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100%. The baseline for zero parameters is 4, as there is nothing to explain. The description correctly avoids fabricating parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '民航客座率及载运率' (civil aviation passenger load factor and load factor) from Sina Finance, which conveys the subject matter. However, it lacks an explicit verb like 'retrieve' or 'get', relying on the tool name and title to imply the action. It does distinguish from siblings by naming a specific macro indicator, but the absence of a clear action verb makes it moderately clear rather than fully 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/5Does 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 the many other macro_china_* tools. There is no mention of alternatives, prerequisites, or suitable contexts. Only the data source URL is given, which is not usage guidance. The intended use is merely implied by the title and name.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover the safety and side-effect profile. The description adds the data source URL and date range, but does not disclose other behavioral traits such as column details, missing data handling, or rate limits. This is similar to the get_calls example where annotations carry the main safety profile and the description adds some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with key information, including the data type, date range, source URL, and return type. However, it repeats '中国年度 PMI 数据' twice (once at the beginning and once in the :return: line), which is slightly redundant but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with 0 parameters and no output schema, the description provides essential facts: data type, date range, source, and return type. However, it is ambiguous about the exact data content (e.g., whether it includes manufacturing vs. services PMI, what columns are present) and does not clarify the meaning of '年度' in the context of a date range starting 2005-02-01. This leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and an empty input schema, so there are no parameter semantics to explain. The baseline for 0 parameters is 4, and the description does not need to compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns '中国年度 PMI 数据' (China annual PMI data) with a specific date range and a return type of pandas.DataFrame. It distinguishes from sibling tools like macro_china_pmi by specifying 'yearly' frequency, but does not explicitly say it is manufacturing PMI (though the URL hints at it) and does not directly compare with related PMI siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 such as macro_china_pmi, macro_china_cx_pmi_yearly, or other macro indicators. The description simply states what it returns without any context on appropriate use cases, prerequisites, 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?
The description discloses the return type (pandas.DataFrame) and the data source URL, which adds value beyond the annotations. However, with annotations already declaring readOnly, openWorld, and idempotent hints, the additional behavioral context is limited; it does not mention data granularity, update frequency, or potential network dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only three lines, but the first line largely restates the tool name, and the URL may be of marginal use. It is structured with the title, source, and return type, though the redundancy slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with strong annotations, the description is adequate but not fully complete. It states the source and return type but does not describe the contents of the DataFrame or the time period covered, which would be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The baseline for no parameters is 4, and the description does not need to compensate for any missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource (China industrial producer price index from Eastmoney) but lacks a verb and reads more like a title than an action statement. It does not explicitly say 'get' or 'fetch', making it somewhat vague, though it is distinguishable from generic terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_china_ppi_yearly or other macro indicators. The description does not mention any exclusions or alternative scenarios, leaving the selection entirely 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a source URL and return type (pandas.DataFrame) but does not disclose data frequency, coverage, or limitations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of filler, with the URL and return type being useful additions. However, it repeats '国房景气指数' three times and lacks structured formatting, which slightly detracts from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool with strong annotations, the description is minimally adequate: it names the index and provides a source URL. Yet it omits details on what the index measures, update frequency, and how it differs from other China real estate indicators, so an agent must infer context from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the input schema is empty, so there are no parameter semantics to describe. The baseline for zero-parameter tools is 4, and the description contains no irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 国房景气指数 (China Housing Prosperity Index) and provides a source URL, but it lacks an explicit verb or action (e.g., 'fetches' or 'retrieves'). It does not differentiate from sibling tools like macro_china_new_house_price, though the name is fairly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative macro China tools. The description provides no context for selection, exclusions, or preferred scenarios, leaving the agent to guess based on the name alone.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat these. It adds the return type (pandas.Series), unit (亿欧元), and data range, but does not disclose other behavioral details such as data size or potential pagination. The description is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes two long URLs that are source references, which are not necessary for tool selection or invocation. This adds clutter and does not earn its place. The essential information is brief, but the structure is not clean or purposefully organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description provides core information: report name, date range, return unit, and return type. However, it is ambiguous whether the returned Series contains all historical values or just the current value, and the reporting frequency is not stated. Since the description carries the full burden due to lack of output schema, this ambiguity is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema has no properties, so the baseline for parameter semantics is 4. The description naturally does not add parameter details, but it confirms the tool requires no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Eurozone unadjusted trade balance report) and scope (date range from 1999-02-01 to present). It is specific and differentiates from other macro tools by naming the exact metric, but lacks an explicit action verb and does not directly reference sibling 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/5Does 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 other eurozone macro indicators or trade balance tools. The description only states what the report contains, not the appropriate context 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame) but no additional behavioral traits such as data frequency, coverage period, or rate limits. It does not contradict the annotations, and the added context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title line, a URL, and return/rtype lines. It avoids unnecessary elaboration, and the source URL is informative. However, the structure is fragmented rather than a flowing natural-language sentence, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless data-retrieval tool, the description provides the source, return type, and the specific data item. It does not describe the returned DataFrame's columns, update schedule, or any limitations, but given the simple nature and existing annotations, it is minimally adequate. More context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and schema description coverage is 100%. The description need not explain parameters. The baseline for zero parameters is 4, and there is nothing more to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a noun phrase: '东方财富-经济数据-日本-全国消费者物价指数年率' (Eastmoney - Economic Data - Japan - National Consumer Price Index Year-on-Year Rate). It clearly identifies the specific data resource and differentiates from siblings like macro_japan_core_cpi_yearly by specifying '全国' (national), but it lacks an explicit action verb like 'fetch' or 'get', making it more of a title than a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 usage context, exclusions, or alternative tools. For a parameterless fetch, the intended use is implied by the title, but there is no explicit statement of when this tool is 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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds only the source URL and return type, with no additional behavioral context such as data update frequency or page limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a title, URL, and return type—with no fluff. However, it is terse and lacks any explanatory sentence, but for a simple tool this is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-param data retrieval, the description gives the source, return type, and indicator name. It doesn't specify the historical depth, units, or frequency, but given the annotations and minimal complexity, it's minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is vacuous. Since the description doesn't need to explain parameter usage, the baseline 4 applies. The description's mention of pandas.DataFrame return type adds slight context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact data product (UK core CPI yearly) and states the return type, making the purpose clear. However, it lacks an explicit verb like 'retrieve' or 'fetch', and it essentially repeats the tool name. It does distinguish from siblings like macro_uk_cpi_yearly by specifying 'core'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., macro_uk_core_cpi_monthly or other UK macro indicators). The description provides no usage context, exclusions, or prerequisites.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, providing safety transparency. The description adds that it returns a pandas DataFrame, which is a small behavioral detail. It does not describe potential side effects or data update behavior, but the annotations cover the key safety profile, so 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, containing the title, source URL, and return type. It is not verbose, but it is fragmented into three lines without clear labeling (e.g., 'Returns:') and is mostly in Chinese. Still, it is concise and every line provides useful information, though a cleaner structure would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema, strong annotations), the description is nearly adequate. It provides the source and return type. However, it does not explain what the returned DataFrame contains (columns, date range, interpretation of 'yearly rate'), which could be important for an agent to know. There is also no indication of data freshness or any usage caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage (trivially). The description does not need to explain parameter meanings. The baseline for 0 parameters is 4, and the description appropriately avoids inventing unnecessary parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides UK Rightmove house price index yearly data from Eastmoney, with a specific source URL and return type. It names the exact metric and source, making the purpose unambiguous. It does not explicitly contrast with the sibling tool macro_uk_rightmove_monthly, though the name implies a yearly variant, so no explicit differentiation is present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 does not mention the sibling monthly version or any other related tools, nor does it specify any context or prerequisites. The description only provides a source URL and return type, which are not usage guidelines.
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 already declare readOnlyHint=true and idempotentHint=true, so the description's added value is limited. It does add the source URL and the return type as a pd.DataFrame, which is useful. However, it does not disclose potential requirements like whether a cookie is mandatory for full data access or any pagination/rate-limit behavior, though the simple nature of the query lessens the need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the title and source, followed by parameters and return type. Every line serves a purpose, and there is no filler. The structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and minimal parameter descriptions, so the description must carry more weight. It fails to explain what 'economic data' actually includes, whether the data is from an economic calendar, or how to interpret the returned DataFrame. For an agent selecting between this and similar macro data tools, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does specify the date format (YYYYMMDD) and mentions the cookie parameter, but 'cookie' is just restated without explaining its purpose or when it's needed. The return type is noted, but column semantics are absent. This is adequate but minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (百度股市通-经济数据) and implies the action of retrieving economic data, with a URL and return type. It distinguishes itself from siblings by naming the Baidu Stock Calendar source, though it doesn't explicitly contrast with similar macro data tools. The purpose is understandable but could be more explicit about the specific nature of the data (e.g., calendar events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many macro_* or news_* siblings. The description only lists parameters and return type, leaving the agent to infer usage context. No exclusions, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds that it returns a list, dict, or pandas DataFrame, which is useful behavioral context, but doesn't disclose other behaviors like data freshness, pagination, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded title and a compact docstring for parameters and return. It avoids excessive prose and uses a standard structured format, though the URL line could be integrated more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters and no output schema, the description provides parameter docs and return types but lacks an example, explanation of indicator value semantics, or details on the returned data structure. It's minimally sufficient but has clear gaps for an agent to fully understand the tool's output and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'word' is Chinese input and lists valid indicator values ('entity or desc or avp or tag'), adding meaning beyond the schema. It doesn't elaborate on what each indicator value returns, so it's not perfect, but it covers the key semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'Knowledge Graph interface for financial research', which names the resource but lacks a specific verb like 'query' or 'lookup'. It is distinguishable from siblings by its unique 'knowledge graph' scope, but the purpose is vague about the actual operation performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only provides a general 'financial research' context without saying when this knowledge graph interface is preferable to other NLP or data tools, and no exclusions or alternatives are mentioned.
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 already cover safety (read-only, idempotent, non-destructive). The description adds no behavioral traits such as data freshness, coverage limitations, or error behavior; it merely states the source URL and return type. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of a title, source URL, and return type in three lines. It is front-loaded and free of fluff, though it reads more like a stub than a crafted description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description provides the essential source and return format, but does not describe the DataFrame contents, data update schedule, or any trading-day caveats. Adequate for a trivial tool but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The schema is empty with 100% coverage vacuously, and the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Shanghai Stock Exchange options disclosure for current-day contracts ('上交所期权当日合约'). It distinguishes from sibling tool option_current_day_szse by exchange. However, it lacks an explicit verb like 'retrieve' or 'list', relying on the function name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only states the source URL and return type, with no mention of appropriate contexts, exclusions, or comparison to other option data 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, thoroughly covering the safety profile. The description adds context by specifying the return type (pandas.DataFrame) and providing an example URL, but does not disclose any additional behavioral traits such as rate limits, data freshness, or response structure. This is adequate given the read-only, idempotent nature already disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing a title line, an example URL, and docstring-style parameter/return lines. It is efficiently structured and front-loads the core purpose. However, the first line duplicates the title provided in the annotations, which is redundant. Overall, it is concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one optional parameter, good safety annotations, and no output schema. The description explains the parameter, return type, and shows an example, which covers the basics. However, it omits the distinction between minute and daily historical data (important given sibling tools), does not specify the returned data fields, and offers no usage context. Given the annotations, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'symbol' with zero description coverage, so the description must compensate. The description explicitly defines ':param symbol: REITs 代码' and shows an example URL with a concrete code (508097), which gives the agent a clear understanding of the parameter's purpose. This is sufficient for a single-parameter tool, though it does not explain accepted formats or how to discover valid codes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool provides '历史行情' (historical market data) for Shanghai/Shenzhen REITs from Eastmoney, which is a clear resource and scope. However, it does not explicitly state that it returns minute-level data (despite the 'min' in the name) and does not distinguish itself from the sibling tool 'reits_hist_em'. The description is more of a noun phrase than a specific action, lacking a clear verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'reits_hist_em' or 'reits_realtime_em'. The description does not mention any context, prerequisites, or exclusions. It simply provides a parameter and return type, leaving the agent to infer usage from 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds only the source URL and return type (pandas.DataFrame), without disclosing data update frequency, coverage scope, or other behavioral traits beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, front-loading the resource name and source URL. It uses efficient docstring-like syntax, though it lacks a proper sentence structure and could be more readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool, the description provides the source and return type. However, it does not explain the DataFrame's exact contents (e.g., columns, date range, granularity) or explicitly differentiate it from closely related hog price tools like spot_hog_soozhu, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. With 0 params, the baseline is 4; the description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific data resource (全国瘦肉型肉猪) and source URL, making it clear this tool returns national lean hog price data. It distinguishes from sibling hog tools by the '瘦肉型' qualifier, but lacks an explicit verb like 'fetch' or 'get', relying on the tool name to imply retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many similar sibling hog price tools (e.g., spot_hog_crossbred_soozhu, spot_hog_soozhu). There is no mention of alternatives or selection criteria, leaving the agent to infer the correct choice.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that it returns a pandas DataFrame and includes the source URL, but it does not disclose data shape, frequency, or other behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the title and URL, but includes raw docstring syntax that adds minor noise. Every element conveys some information, and there is no significant verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 gives the essential input but the return is only described as '现货走势' with type pandas.DataFrame, lacking column details, time range, examples, or any constraints. This leaves the agent uncertain about the exact output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a default value for symbol, with no description (0% coverage). The description compensates by stating ':param symbol: 品种名称' (commodity name), clarifying the parameter's meaning, but it does not enumerate valid values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '99 期货-数据-期现-现货走势' with a source URL, indicating it provides spot trend data for commodities from 99qh.com. It specifies the parameter (symbol) and return type (pandas DataFrame), but uses no explicit action verb and does not differentiate from similar futures/spot 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/5Does 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 like futures_spot_price or spot_price_table_qh. The description only lists input and output, providing no context for selection or exclusion.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a source URL and return type (pandas.DataFrame) but does not disclose behavior like date format expectations, pagination, or network dependency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is presented as a docstring with a title, URL, and param blocks. It is reasonably concise but contains redundant and erroneous :type lines (all 'symbol'), which slightly undermine clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns a pandas.DataFrame of allotment implementation plans, which is stated. However, it does not explain the semantics of the date range, whether defaults are acceptable, or what columns are expected. For a straightforward data retrieval tool, this is adequate but lacks helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description manually specifies each parameter: symbol as 股票代码, start_date as 开始查询的日期, end_date as 结束查询的日期, which supplements the schema that has no descriptions. However, the :type annotations are incorrectly repeated as 'symbol' for all params, and the date format is not explicitly stated beyond the default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '巨潮资讯-个股-配股实施方案' (Cninfo - Individual Stock - Rights Issue Implementation Plan), clearly identifying the resource and data source. However, it lacks an explicit verb like '获取' or 'query', and it doesn't explicitly distinguish itself from sibling stock-related tools beyond the topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as stock_dividend_cninfo or other Cninfo-based stock tools. It only lists parameters and return type, with no context, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety traits. The description adds that the return is a pandas.DataFrame and includes a source URL, but provides no additional behavioral context such as data freshness, filtering, or error 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded with the source and example URL, followed by clear param/return documentation. Every element serves a purpose, but it lacks a more organized structure that would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should detail what the DataFrame contains (e.g., bid/ask prices, columns), but it only says '行情报价'. It also omits usage context, such as whether this is for a single stock only or how to handle different exchanges, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that 'symbol' is a stock code (股票代码) of type str, which adds meaning beyond the raw schema. However, it doesn't specify the code format (e.g., 6-digit, exchange prefix) or clarify why the default is '000001', so it only partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a market quote (行情报价) from East Money, with a URL example and stock symbol parameter. However, it doesn't explicitly mention bid/ask or differentiate from other stock quote tools like stock_zh_a_spot_em, so it's clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the numerous sibling stock market tools. There is no mention of alternatives, exclusions, or scenarios where it's preferred, leaving the agent without direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only a source URL and return type, with no additional behavioral context such as data coverage, rate limits, or output format nuances beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a structured docstring with :param and :return lines, making it easy to parse. The URL takes some space but is a useful reference. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides parameter meanings and return type, which is adequate for a simple historical data tool. However, it does not explain what the period values mean (e.g., 5-minute intervals), how to obtain valid symbol names, or the shape/columns of the returned DataFrame, leaving gaps given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 0% coverage, the description compensates by documenting both parameters: symbol is described as '板块名称' (board name) and period is given an explicit choice set {'1', '5', '15', '30', '60'}. This adds meaningful semantics beyond the naked schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '分时历史行情' (minute historical quotes) for concept sectors on Eastmoney, which clearly identifies the resource and data type. However, it lacks an explicit verb like 'get' or 'retrieve' and does not differentiate from sibling tools such as stock_board_concept_hist_em or stock_board_industry_hist_min_em, though the name itself conveys the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, target use cases, or exclusions, leaving the agent to infer usage solely from the tool name and description.
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 already declare the tool read-only, idempotent, and non-destructive. The description adds that it returns a pandas.DataFrame and describes the date parameter, but it does not disclose behavioral traits such as how the date filters data, pagination, or any special handling. It does not contradict annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and contains only essential information: source, parameter, and return type. It avoids unnecessary fluff, but the structure mixes a Chinese title, a URL, and docstring syntax, which is not perfectly coherent. It is appropriately sized but could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description should provide more detail about the returned data's fields or scope. It only says '股权质押' without explaining what columns or coverage the result includes. This makes it hard for an agent to determine if the tool suits a user's specific need, especially with many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the 'date' parameter. It states '开始统计时间' (start statistical time) and specifies it as a string, which gives basic meaning. However, it does not explicitly state the expected format (e.g., YYYYMMDD) beyond the default value, leaving some ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving equity pledge (股权质押) data from Cninfo's thematic statistics under corporate governance. The resource and domain are specific, and the name distinguishes it from sibling tools like stock_cg_guarantee_cninfo. However, it lacks an explicit action verb like 'retrieve' or 'fetch', making it slightly less direct than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 excluded cases, prerequisites, or recommended contexts. The only context is the category in the title, which is more about purpose than usage, leaving the agent without clear decision-making information.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered. The description adds only the return type (pandas.DataFrame) and does not disclose any other behavioral traits like data freshness, network dependencies, or limitations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a clear docstring structure with param/return sections. The inclusion of a sample URL is slightly extraneous but does not significantly detract from clarity. It is front-loaded with the tool title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should describe what the resulting DataFrame contains. It only names the return type and title, without listing columns, examples, or data granularity. It also fails to differentiate from the nearly identical sibling stock_financial_cash_ths, making it adequate but incomplete for an agent to fully predict the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description documents both parameters: symbol as stock code and indicator with an explicit choice list including defaults. This adds meaningful semantic value beyond the schema, though it could provide further explanation of each indicator option.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '同花顺-财务指标-现金流量表' (THS financial indicator cash flow statement) and states it returns a pandas DataFrame of that statement, clearly indicating the resource. However, it lacks an explicit verb like 'get' and does not distinguish itself from the sibling tool 'stock_financial_cash_ths'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_financial_cash_ths, stock_financial_abstract_ths, or other financial statement tools. The description only lists parameter choices and does not mention exclusions or preferred contexts.
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 already declare the tool safe (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar for additional disclosure is lower. The description adds only that it returns a pandas DataFrame, but gives no extra behavioral context such as data coverage, rate limits, or error behavior, which is a minimal addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but repetitive, repeating '同花顺-财务指标-现金流量表' three times and including raw URLs and a Python docstring format. It does not front-load a clear action sentence, and some content (e.g., the hardcoded example symbol 000063 in URLs) is not explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fails to explain what the returned DataFrame contains (columns, index, etc.). It also does not specify which stocks are supported (e.g., A-shares only) or any limitations, so an agent cannot fully judge if it meets a user's needs. The tool is simple, but the description lacks key contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description's parameter docs add crucial meaning: symbol is 股票代码 (stock code) and indicator specifies the choice set {按报告期, 按单季度, 按年度}. This compensates for the schema gap, though it lacks format validation or explicit examples beyond the defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving the cash flow statement from 同花顺 (TongHuaShun) via the title and URLs, making the resource clear. However, it lacks an explicit verb like 'fetch' or 'get', and does not distinguish itself from closely related sibling tools such as stock_financial_cash_new_ths or stock_cash_flow_sheet_by_report_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 supported markets (e.g., A-shares), prerequisites, or exclusions, so an agent cannot determine its appropriate context beyond the implicit source and financial statement type.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type but does not disclose additional behavioral traits such as data scope, pagination, or data freshness. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with source URL, parameter, and return sections. Every line carries information, though a brief summary sentence at the beginning would improve front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema, so the description should clarify the scope of the returned data. It only states '十大流通股东' without specifying whether this covers all stocks or a particular stock, nor what columns are included. This ambiguity is a significant completeness gap for an agent selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does add meaning by documenting 'date' as 报告期 (report period) with type str, but it does not specify the expected format (e.g., YYYYMMDD) or whether any specific date constraints apply. The schema default '20230930' hints at format but is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (股东持股分析-十大流通股东) and return type (pandas.DataFrame of top 10 free shareholders), making the core purpose clear. However, it lacks a strong verb (e.g., 'fetches', 'queries') and does not differentiate from closely related siblings like stock_gdfx_free_top_10_em or stock_gdfx_holding_analyse_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or context for selection. The description merely restates the data source and parameter without explaining use cases or distinguishing from similar 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?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds that it returns a pandas DataFrame of top 10 circulating shareholders and that the date is the report period. It does not disclose additional behavioral traits such as data update frequency, pagination, or quirks, but given the annotations this is acceptable, though minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a title line, URL, param, and return type, which is readable. However, it redundantly repeats the annotation title verbatim at the start, and the URL adds length without immediate value for an agent. Every line earns some place, but the redundancy and unnecessary URL make it less concise than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, read-only, no output schema), so the description covers the basics: source, parameter, and return type. However, it does not explain the contents of the returned DataFrame (e.g., columns like shareholder name, change in shares, holding ratio), nor does it clarify whether the data covers all stocks or a specific stock. Without an output schema, this lack of detail leaves the agent partially informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for 'date' (0% coverage), so the description's ':param date: 报告期' adds crucial meaning—it clarifies the parameter is the report period. It also states the type as str. However, it does not specify the required format (e.g., YYYYMMDD) beyond what the schema default implies, and it doesn't explain acceptable values like quarter-end dates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (East Money), the category (shareholder holding change statistics), and the target (top 10 circulating shareholders). It also documents the report period parameter and return type. However, it lacks an explicit verb like "retrieves" and doesn't clearly distinguish itself from sibling tools like stock_gdfx_free_holding_analyse_em, aside from the tool name and the phrase "持股变动统计" in 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/5Does 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 such as stock_gdfx_free_holding_statistics_em or stock_gdfx_top_10_em. The description does not explain the context (e.g., for a specific report period, all stocks) or any prerequisites. The URL and parameter hint at usage but do not provide explicit selection criteria.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is useful context beyond annotations. However, it does not disclose any additional behavioral traits such as pagination, rate limits, or error conditions. With annotations present, the description provides marginal extra value, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a title line, a URL, and a clear parameter/return docstring. It front-loads the purpose and avoids unnecessary verbosity. The URL is extra but useful for source verification. It earns a 4 for efficiency and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but there is no output schema, so the description must explain the return value. It only says '十大流通股东' (top 10 circulating shareholders) without listing columns or DataFrame structure. Also, with a large family of sibling tools like stock_gdfx_free_holding_detail_em and stock_gdfx_holding_statistics_em, the description does not differentiate what makes this tool distinct. This is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the burden. The docstring ':param date: 报告期' clarifies that the `date` parameter means 'reporting period', and the default value '20210630' implies a YYYYMMDD format. This adds meaning beyond the schema property name, but it is minimal—no valid range, format specification, or examples beyond the default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the data source and content: '东方财富网-数据中心-股东分析-股东持股统计-十大流通股东' (East Money Data Center - Shareholder Analysis - Shareholder Holding Statistics - Top 10 Circulating Shareholders). It implies a retrieval function by specifying return type pandas.DataFrame. However, it does not explicitly distinguish from closely named siblings like stock_gdfx_holding_statistics_em, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply provides a URL and parameter documentation, with no mention of appropriate contexts, exclusions, or why one might choose this over the many similar stock_gdfx_* tools. This is a clear absence of usage guidance.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds only the data source URL and return type (pandas.DataFrame), but no additional behavioral context such as pagination, rate limits, or the meaning of the returned data. It does not contradict annotations, but it also provides little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and uses a standard docstring format, front-loading the source and return type. However, it repeats the URL twice (in the description and the param doc), which is minor redundancy. Overall it is appropriately sized and gets to the point quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description provides the essential source, param meaning, and return type. It does not explain the output columns, whether the data is per-company or aggregate, or any relationship to the detail variants. Given the lack of an output schema, slightly more detail about the returned DataFrame would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (date) with no description, and schema coverage is 0%. The description compensates by explaining that date is a specified trading day and points to the URL for valid values, along with the default format evident from the schema's default value '20240906'. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides the pledge ratio for listed companies from Eastmoney, with a specific URL and data domain. It identifies the resource (上市公司质押比例) and the verb is implicit in the function name. However, it does not explicitly differentiate itself from sibling tools like stock_gpzy_pledge_ratio_detail_em, which is a detail variant, so it's not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It only mentions that the date parameter can be queried by visiting the URL. There is no comparison to the many related stock_gpzy_* tools or any exclusions for when this tool should be preferred.
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 already establish that this is a read-only, idempotent operation, so the description doesn't need to restate that. It adds the return type (pandas.DataFrame) and a source URL, which provides some context, but it does not disclose the contents of the DataFrame or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a clear docstring structure with source URL, parameter, return, and rtype. The URL is somewhat lengthy, but each line serves a purpose; it's not padded with fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the output type but not the actual fields or structure of the returned DataFrame. It also lacks any context to help an agent decide if this is the right tool among many HK stock tools, making it incomplete for selecting and invoking correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, so the param docstring ('股票代码' meaning stock code) adds meaning beyond the raw schema. However, it lacks details about the code format, examples, or constraints, leaving the agent with only a general sense of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches Hong Kong stock company profile data from East Money and returns it as a pandas DataFrame. However, it does not differentiate it from sibling tools like stock_hk_security_profile_em, and the Chinese title largely mirrors the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention any conditions, exclusions, or scenarios, so the agent gets no help in choosing this tool over related HK stock 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the source (Eastmoney), market (HK), and context (industry comparison), plus the pandas DataFrame return type. However, it does not disclose deeper behavioral traits such as pagination, rate limits, or data freshness. Given the annotations cover the safety profile, the description provides adequate but not rich additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but the long URL is unnecessary clutter and the structure is fragmented (title, URL, then docstring-like param/return lines). The core information is present but could be better organized with a clearer separation between purpose and technical details. It earns a middle score for being reasonably concise while having some structural noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the annotations provide the safety context. The description identifies the source, market, purpose, parameter, and return type. However, it does not specify what 'valuation comparison' actually contains (e.g., PE, PB, EV/EBITDA) or any details about the returned DataFrame. For a simple lookup tool, this is adequate but not fully complete, as the agent may not know the exact output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It states that 'symbol' is the stock code (股票代码), which adds basic meaning beyond the schema. However, it does not provide format examples, constraints, or explain how the code should be formatted (e.g., leading zeros, exchange suffix). The default value '03900' indirectly suggests the format, but the description could be more explicit. This is a minimal but sufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Eastmoney - HK Stocks - Industry Comparison - Valuation Comparison', which specifies the resource (HK stocks), the source (Eastmoney), and the purpose (industry valuation comparison). This distinguishes it from A-share counterparts like stock_zh_valuation_comparison_em and other sources like stock_hk_valuation_baidu. However, it lacks an explicit verb like 'retrieve' or 'get', making it slightly less direct than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions, prerequisites, or scenarios where another tool would be more appropriate. The URL is a reference page but is not explained. The agent is left to infer usage context solely from the name and title.
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 already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds the data source URL and return type (pandas.DataFrame), but no additional behavioral context such as rate limits, pagination, or column specifics. This is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title, URL, and return type. It is not verbose, though the phrase '人气榜' appears twice and the structure is a bit repetitive. Overall, it is efficient for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description should clarify the return contents. It indicates a DataFrame of popularity rankings and provides the source URL, but it does not describe expected fields (e.g., stock code, rank, popularity score). This leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to compensate for schema gaps. The baseline of 4 applies, and the description correctly limits itself to the return type without adding irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('个股人气榜' – individual stock popularity ranking) and provides a source URL, but it lacks a clear verb and is essentially a title. It does not differentiate from sibling rank tools like stock_hot_rank_detail_em or stock_hot_rank_latest_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what it should be used for, or when to prefer an alternative. It solely states what it is without any contextual usage direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and the data source URL, which provides minor behavioral context beyond the annotations, but it does not describe pagination, rate limits, or any other side effects. This is adequate given the low complexity, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, URL, parameter docs, and return type. It is front-loaded with the purpose and contains no fluff. Each line serves a function, keeping it appropriately sized for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description covers the source, parameters, and return type. However, it does not specify what columns the returned DataFrame contains, nor does it clarify the date format beyond the default example. This is a viable description but leaves a noticeable gap in the output contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It explicitly documents both parameters: symbol with enumerated choices (证监会行业分类, 国证行业分类) and date as '查询日期' (query date). The default value '20210910' implies a date format, but the description does not explicitly state it. Overall, it adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the tool's title '巨潮资讯-数据中心-行业分析-行业市盈率' (CNInfo Data Center - Industry Analysis - Industry P/E Ratio), which clearly identifies the data resource and metric. While no explicit verb like 'get' is used, the noun phrase and URL context make the purpose unambiguous. It distinguishes itself from sibling tools by naming the specific cninfo industry PE ratio dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or compare with similar tools like stock_index_pe_lg or stock_a_ttm_lyr. An agent selecting among the many stock valuation tools would have no help from this description.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety expectations. The description adds minimal context beyond the return type and a broad list scope, such as what columns might be included or that it is a reference list. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, consisting of a title and a return type annotation. It is front-loaded and efficient, though slightly under-specified for the return data's actual content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and a simple list operation, the description is adequate but lacks details about the returned DataFrame's columns (e.g., whether it includes code and name only) or any caveats like market coverage. Sibling confusion is possible without more specificity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so parameter semantics are trivially complete. Per the rubric, a baseline of 4 applies for 0-parameter tools, and the description does not need to explain nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '沪深京 A 股列表' (Shanghai, Shenzhen, Beijing A-share list) and return type as DataFrame, making it clear the tool provides a list of A-shares. However, it does not differentiate from sibling tools like stock_zh_a_spot_em or stock_bj_a_spot_em, and the description is essentially a noun phrase without an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 what it returns, not the context or exclusions, and no sibling comparisons 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and the fact that it is a 7x24 global financial news feed from a specific URL, which is useful context. However, it does not disclose details about the DataFrame contents or any other behavioral nuances beyond what annotations already cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three short lines: the title, the source URL, and return type information. Every line adds some information (title, source, output type), and there is no redundant filler. It is appropriately structured for a simple no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations, the description is mostly sufficient, but it does not explain what the returned DataFrame contains (e.g., columns like time, headline, URL). Since there is no output schema, the description bears the burden of describing the return values, and it only states '全球财经快讯' without structural details, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (vacuously). Per the rubric, a baseline of 4 is appropriate since the description has no need to explain parameters. No additional parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says '新浪财经-全球财经快讯' and ':return: 全球财经快讯', which restates the tool's title and indicates it returns global financial news. It is not a tautology because it adds the source URL and a return type, but it lacks an explicit verb like 'fetch' or 'list' and does not clearly distinguish from sibling tools such as stock_info_global_em or stock_info_global_ths beyond the source name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its siblings (e.g., stock_info_global_cls, stock_info_global_em, stock_info_global_futu, stock_info_global_ths). The description does not mention any exclusions or alternative tools, so an agent has no context for selecting this specific source.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a source URL and return type (pandas.DataFrame), which is useful but does not reveal behavioral traits like data coverage, update frequency, or volume. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with source and resource, but it redundantly repeats '东方财富网-数据中心-新股数据' and '首发申报企业信息' multiple times. The URL and return type documentation are useful, but the repetition means not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should detail what the returned DataFrame contains, but it only names the category '首发申报企业信息' without listing any columns, fields, or examples. There is no explanation of how data is organized or filtered, leaving an agent without enough context to fully understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has no properties, so there is nothing to explain. The description appropriately focuses on the returned entity type, and with no parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource: 东方财富网数据中心新股数据-首发申报企业信息, and provides a URL to the exact data page. It indicates the tool returns IPO declaration enterprise information as a pandas DataFrame. However, it lacks an explicit action verb like 'Get' or 'Return', and its differentiation from sibling ipo tools is only implicit through the specific data category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling stock_ipo_* tools, nor does it state any exclusions or prerequisites. The agent must infer usage solely from the name and description, which is insufficient for choosing among alternatives.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered. The description adds minimal behavioral context: it's a scraper for a specific Eastmoney page, returns a pandas DataFrame, and requires a start date. It doesn't describe error behavior, rate limits, or pagination, but with annotations covering safety, this is acceptable though 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a clear title, URL, param doc, and return type. It uses a consistent docstring format. The lines are short and informative, though the URL line could be considered redundant and the name itself is very long. Overall, every part earns its place, but the format is a bit terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's medium complexity (1 param, no output schema, no nested objects), the description is incomplete. It doesn't specify the exact structure of the returned DataFrame, what columns to expect, or whether the date parameter is inclusive/exclusive. The URL adds context but doesn't substitute for missing return schema details. With siblings like stock_jgdy_tj_em, more behavioral hints would help disambiguate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description carries the burden of explaining the 'date' parameter. It says 'date: 开始时间' (start time) and provides a default example '20241211', roughly implying a YYYYMMDD format. This is minimal but some meaning is conveyed. However, it's not clear if this is a start date for a range or a specific reporting date, and no details on format variations are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly says it retrieves institutional research details (机构调研详细) from a specific Eastmoney data center page. The verb 'detail' is specific, but it could be confused with sibling tool stock_jgdy_tj_em (机构调研统计) which is about the same domain. It distinguishes by saying '详细' (detail) rather than '统计' (statistics), but doesn't 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It mentions the URL and a single parameter (date), but does not state prerequisites, limitations, or when a user would prefer this over the statistical sibling tool. The context implies it's for historical institutional research detail data, but no clear usage scenario is 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds modest context: the source URL on East Money and the pandas.DataFrame return type. It does not disclose deeper behavioral traits like rate limits or data coverage, but it does not contradict the annotations either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—title line, URL, and a short docstring—with essentially no fluff. A minor deduction applies because the first line exactly duplicates the title annotation, adding redundancy, and the raw docstring format (param/type/return/rtype) is serviceable but not polished prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity: one parameter, no output schema, and strong annotations. The description covers the data source, parameter semantics, and return type (pandas.DataFrame). However, with no output schema present, the description omits any detail about the columns or fields in the returned transaction data, leaving the agent without a clear picture of the data shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the docstring carries the full burden and compensates well: it explains that symbol is a 营业部代码 (department code), provides an example value "10188715", and instructs that valid codes come from the stock_lhb_hyyyb_em() interface. This goes beyond the bare schema field (type/string/default) by adding semantic meaning, an example, and provenance for valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's first line restates the title verbatim (东方财富网-数据中心-龙虎榜单-营业部历史交易明细-营业部交易明细), conveying the resource via noun phrases rather than an explicit verb. The tool name and docstring clarify that it fetches historical transaction details for a specific 营业部 code from East Money, but it does not distinguish itself from the many LHB siblings such as stock_lhb_detail_em or stock_lhb_stock_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The only usage hint is that the symbol can be obtained via ak.stock_lhb_hyyyb_em(), which points to a sibling tool but does not explain when this tool is appropriate versus the roughly twenty other LHB-related siblings. The description offers no exclusion criteria 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds little beyond the return type (pandas.DataFrame) and the source URL. It does not disclose date format requirements, pagination, or any other behavioral traits, but with strong annotations this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a title line, a source URL, and structured param/return docstring entries. It avoids unnecessary prose and is easy to scan. The docstring formatting is standard and appropriate for the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain the return data; it only says '融资融券明细' (margin trading details) as a DataFrame. It lacks column names, data granularity (daily vs. historical), or any explanation of what fields are included. For a financial data tool, this is insufficient for an agent to confidently use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents the 'date' parameter as '交易日期' (trading date), which adds meaning over the schema's raw string type. However, it does not specify the expected format (e.g., YYYYMMDD) beyond the default value, and no additional constraints or examples are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's first line names the resource and scope: Shenzhen Stock Exchange margin trading transaction details. Although it lacks an explicit verb like 'retrieve' or 'list', the 'return' field (DataFrame) makes it clear this is a data retrieval tool. The exchange and '明细' (details) distinction help set it apart from summary or other-exchange margin tools, though it relies heavily on the tool name for full disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_margin_detail_sse or stock_margin_szse. There is no mention of use cases, exclusions, or prerequisites. The URL is a source reference but not usage guidance.
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 already declare this as a read-only, idempotent operation. The description adds that it accepts a trading date and returns a pandas DataFrame, which is useful context beyond the annotations. However, it does not disclose any further behavioral traits such as response structure, pagination, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with a title-like sentence followed by a brief docstring. It is not overly verbose and is well-structured, though it is arguably under-specified in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with one optional parameter, but the description lacks detail on what 'underlying securities information' includes. Without an output schema, the description should clarify the return values, but it only says '标的证券信息' and the return type, leaving ambiguity about the data's structure and content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, date, with no description. The description/docstring states this is a trading day (交易日), adding some meaning. However, it does not specify the expected format (though the default suggests YYYYMMDD) or any validation rules. Given 0% schema coverage, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Beijing Stock Exchange margin trading underlying securities information. It specifies the market (BSE) and the data category, distinguishing it from similar tools like stock_margin_underlying_info_szse. However, it lacks an explicit verb like 'retrieve' or 'list,' relying on the noun phrase to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states the data content without any mention of alternatives, exclusions, or prerequisites. The tool name and sibling context hint at the use case, but the description itself offers no usage direction.
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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. However, the description adds no behavioral context beyond stating it returns a pandas DataFrame; there is no mention of data freshness, pagination, rate limits, or any caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured, with a clear title, source URL, parameter documentation, and return type. It avoids unnecessary verbosity, though it could be more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the key filter options, but the return description '创新低数据' is vague and does not specify what columns or data elements are included. With no output schema, this leaves some ambiguity about the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string type with a default value and no descriptions (0% coverage). The description compensates by listing the valid choices for the 'symbol' parameter: 创月新低, 半年新低, 一年新低, 历史新低, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as THS data center technical stock selection for new lows, with a specific URL. The title '创新低' (new lows) distinguishes it from sibling rank tools like stock_rank_cxg_ths (创新高). The purpose is evident, though it lacks an explicit verb like 'list' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative ranking tools or other data sources. The description only includes parameter documentation and a URL, with no mention of use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the source URL and return type, but does not disclose any additional behaviors like data frequency, granularity, or pagination. With annotations carrying the main burden, this is acceptable but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and structured with a title, URL, and return annotations, making it compact. However, it repeats '持续放量' multiple times (in the title and return statement), causing slight redundancy. It could be more informative without added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should at least sketch what the returned DataFrame contains (e.g., stock codes, names, volume statistics). It only says '持续放量', which is vague and leaves the agent uncertain about the exact output structure or what criteria define the ranking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input. The description repeats the return type but adds no parameter semantics, which is appropriate for a parameterless tool. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as THS Data Center technical stock selection for '持续放量' (continuous volume increase), which clarifies the cryptic 'cxfl' in the tool name. However, it lacks an explicit verb like 'fetch' or 'list' and does not detail what qualifies as continuous volume, so it is more of a label than a full purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its many sibling tools such as stock_rank_cxd_ths or stock_rank_cxg_ths. The description simply states the ranking name without any context for selection 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns a pandas DataFrame of downward-breakout stocks and enumerates the supported moving-average periods. It does not disclose data recency, market scope, or pagination, but the read-only nature is clear from annotations. No 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a docstring format with a first line identical to the annotation title, which is redundant. The URL, parameter, and return type lines are useful, but there is no crisp imperative sentence describing the tool's function. It is compact but not optimally structured for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and safety annotations, the description should at least outline what the returned DataFrame contains (e.g., stock codes, names, breakout dates). It only states 'return: 向下突破' and 'rtype: pandas.DataFrame', leaving the output structure and data scope unexplained. This is a significant gap for an agent deciding if the tool meets its needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines symbol as a string with a default, providing no enum or explanation (0% coverage). The description compensates by listing all allowed values ('5日均线' through '500日均线') and indicating they represent moving average periods. This is actually more informative than a typical enum, as the values are self-descriptive. It lacks a definition of what 'symbol' means in context, but the choices are sufficiently clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's first line '同花顺-数据中心-技术选股-向下突破' clearly identifies the resource and action: a THS data center technical stock selection tool for downward breakouts. The URL and parameter list reinforce this, and the term '向下突破' distinguishes it from sibling rank tools focused on other metrics (e.g., 向上突破). It stops short of a full sentence stating 'returns stocks that broke below the given moving average,' so it's clear but not maximally 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/5Does 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 stock_rank_xstp_ths (likely upward breakout) or other stock_rank_* tools. It only lists the source and parameters, leaving the selection criteria to the agent's interpretation. No exclusions or recommended contexts are given.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type, but no additional behavioral details such as rate limits or data freshness. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three lines) and front-loaded with the title, but the first line simply repeats the tool's Chinese title, which is redundant with the 'title' annotation. Still, it's concise with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only data retrieval tool with no output schema, the description provides the source URL and the general output type. However, it does not explain what '险资举牌' data contains (e.g., columns, stock codes, time coverage), leaving some ambiguity for an agent deciding if this tool is relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly does not attempt to document parameters; no param-related guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (同花顺-数据中心-技术选股-险资举牌) and return type (pandas.DataFrame), but lacks an explicit verb like 'get' or 'list'. It mostly restates the tool's name/title, making it somewhat tautological. It doesn't distinguish itself from sibling stock_rank_*_ths tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other stock_rank_*_ths tools or alternatives. No when-to-use or when-not-to-use information is 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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and a URL, but does not disclose any other behaviors such as data freshness, pagination, or error handling. Given the simple read-only nature, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and to the point: it gives the data source, a URL, the semantic meaning, and the return type in three lines. There is no redundant text, though the lack of a fuller description is a slight drawback.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool, this is minimally complete: it states the origin, the content (qualified enterprises from IPO review), and the DataFrame return. However, it does not describe the DataFrame columns or any specifics about the data, and the absence of an output schema leaves the agent guessing about the exact structure. The simplicity of the tool makes this acceptable but not excellent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%, so there are no parameter semantics to explain. The baseline for a no-parameter tool is 4, and the description does not need to compensate for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source and content ('IPO审核信息-达标企业') and states the return type, but it lacks an explicit action verb (e.g., 'fetch' or 'list') and does not distinguish this tool from sibling tools like stock_register_cyb or stock_register_all_em that likely serve similar purposes. It is more a title than a functional 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/5Does 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 exclusions, prerequisites, or scenarios where another tool should be used. It simply states the data source and return type.
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 already declare readOnly, non-destructive, idempotent, and open-world behavior. The description adds the source URL and return type (pandas DataFrame) but does not disclose additional behavioral traits such as rate limits, data currency, or scope limitations. Since annotations are strong, the minimal additional context is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear title, source URL, and docstring-style param/return lines. It avoids unnecessary fluff, though the return line largely repeats the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should elaborate on the returned data structure. It only restates '董监高人员股份变动' and 'pandas.DataFrame' without mentioning columns, date ranges, or other relevant details. For a data retrieval tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'symbol' parameter (0% coverage). The description explains it accepts either '全部' or a specific stock code, adding meaning beyond the schema's bare type. However, it does not specify the exact format for stock codes (e.g., with exchange suffix), leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (SZSE) and content (director/supervisor/executive share changes) via its title and URL, which distinguishes it from similar SSE/BSE tools. However, it lacks an explicit verb like 'get' or 'list,' relying on the function name and structure to imply retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like stock_share_hold_change_sse or stock_share_change_cninfo. The parameter description hints at filtering by stock code but does not explain selection criteria or when to choose '全部' vs a specific code.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame), which is useful context, but does not disclose rate limits, pagination, or data freshness. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring containing source, URL, parameter docs, and return docs. It includes redundant repetition of '每日互动' and hardcodes an example URL, but overall is efficient and front-loaded with the data source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with strong annotations and no output schema, the description covers the parameter and return type adequately. However, it does not specify the columns or metrics contained in the valuation analysis, nor any nuances about supported exchanges or code formats, leaving it minimally sufficient rather than rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines only symbol as a string with default '300766'. The description explicitly states ':param symbol: 股票代码' (stock code) and type str, providing meaning beyond the raw schema, especially for non-Chinese-speaking agents. The default value offers format hint, though no explicit format string is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (东方财富网 East Money) and data type (估值分析 valuation analysis) with a URL, implying the tool retrieves valuation data for a given stock code. However, it lacks an explicit verb like 'fetch' or 'return', and the repeated '每日互动' (a specific company name) introduces ambiguity about whether the tool is generic or stock-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 similar valuation tools such as stock_zh_valuation_baidu or stock_hk_valuation_comparison_em. No conditions, exclusions, or prerequisite details are provided, leaving the agent without decision support.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame) but provides no additional behavioral details such as rate limits or data update frequency. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes essential information: source path, URL, and return type. It is not overly verbose, though the placement of the URL in the middle of the text slightly disrupts flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description provides enough to know it fetches new stock first-day data. However, with no output schema, it does not describe the data columns or provide any usage context, leaving some ambiguity about what the returned DataFrame contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The baseline for 0 parameters is 4, and the description adds no extraneous parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (同花顺-数据中心-新股数据-新股上市首日) and provides a URL and return type, but lacks an explicit verb like 'get' or 'list'. It is specific to new stock first-day listing data, which distinguishes it from sibling IPO tools, but the purpose is implied rather than directly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related IPO tools like stock_ipo_ths or provide any context for when this data would be relevant.
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 already declare readOnlyHint=true and destructiveHint=false, which convey safety. The description adds the data source (Eastmoney) and return type (pandas.DataFrame) but does not disclose additional behaviors like pagination, rate limits, or data granularity beyond the period parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a URL, parameters, and return type. It is reasonably concise, but the URL and repetitive type annotations add some clutter. It is front-loaded with the main purpose, which helps readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only states '每日分时行情' and 'rtype: pandas.DataFrame' without describing the DataFrame's columns or indexing. It also lacks context on limitations, such as data frequency or potential web scraping issues, leaving important information for a tool with no structured output definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by detailing each parameter, including period choices ('1','5','15','30','60') and adjust choices ('', 'qfq', 'hfq'). It also states parameter types (str), adding meaningful semantic information beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves daily intraday quotes (每日分时行情) for A-shares from Eastmoney, with a specific verb and resource. It distinguishes itself from daily historical tools like stock_zh_a_hist by its focus on minute-level data, though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lacks any mention of use cases, exclusions, or comparisons to related tools such as stock_zh_a_hist or stock_zh_a_minute, leaving the user to infer the appropriate context.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the return type (pandas.DataFrame), data source URL, and the pre-market inclusion, which are useful but do not disclose deeper behaviors such as date handling, rate limits, or data granularity specifics. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the source and data type, and uses a structured docstring format for parameters. The URL is potentially distracting but not excessive. No significant redundancy beyond the title repeating in both description and annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical context such as how the date is determined (no date parameter), what the output DataFrame columns are, and how pre-market data is defined. This is especially problematic because the tool name says 'hist' yet there is no date parameter, making it unclear whether this returns data for a single day or requires external date context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description compensates minimally by providing parameter types and Chinese descriptions for symbol, start_time, and end_time. However, the descriptions are terse ('股票代码', '开始时间', '结束时间') and lack format examples or constraints beyond the defaults, leaving ambiguity about symbol format and time semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing pre-market and intraday minute data for Shanghai/Shenzhen/Beijing A-shares from East Money, which distinguishes it from regular A-share minute history tools like stock_zh_a_hist_min_em. The verb '获取' is implicit but the resource and data scope are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description only states what it returns, without mentioning scenarios or exclusions. The 'pre-market' distinction is implied by the name and title but never turned into actionable advice for tool selection.
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 already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, which cover the safety profile. The description adds some behavioral context by explaining the 'adjust' parameter (qfq/hfq) and noting the data source URL, but it does not disclose additional traits such as rate limits, pagination, or error behavior. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, covering purpose, source, and parameters in a compact block. The URL is slightly extraneous but not verbose. The docstring format is structured and easy to parse, though it could be more front-loaded with a clear one-line purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description must explain return values. It only says ':return: specific data' with rtype pandas.DataFrame, which is vague and lacks detail on columns or data structure. It also does not specify date range coverage or exchange scope, leaving significant gaps for an agent to infer how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage (0%), so the description must compensate. It does so effectively: it documents 'symbol' with the example 'sh900901', gives the allowed values for 'period' (1, 5, 15, 30, 60), and explains 'adjust' values (empty for unadjusted, qfq for forward-adjusted, hfq for backward-adjusted). This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides historical minute data for stocks and indices, which is a clear general purpose. However, it does not explicitly mention B-shares (as the name implies), making it difficult to distinguish from other Chinese stock minute-data tools like stock_zh_a_minute or stock_zh_a_hist_min_em. The example symbol sh900901 hints at B-shares, but that is in the parameter docs, not the purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 state that it is for B-share minute data or contrast with A-share tools. There is no 'when not to use' or named alternatives, so an agent cannot easily determine the right 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds the return type and a source URL, but does not disclose any additional behavioral traits such as rate limits, error behavior, or what happens with invalid symbols. With annotations covering the safety profile, this is acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a URL, parameter documentation, and return type. Each line serves a purpose. However, the format is a somewhat fragmented docstring rather than a coherent sentence, and the URL is long. Overall, it is reasonably concise without excess verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description provides the essential pieces: source, parameter explanation, and return type. However, it does not elaborate on what fields the valuation data contains, whether it is time-series or current, or any other expectations. Given the lack of an output schema, a bit more detail about the returned DataFrame would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the parameter name and a default value, with no description. The description compensates by explaining '指数代码' (index code) and giving an example 'H30374'. Since there is only one parameter and the description clearly defines its meaning, it adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description title '中证指数-指数估值数据' clearly identifies the resource as China Securities Index valuation data. The parameter/return docstring indicates it returns a pandas DataFrame of valuation data for a given index symbol, which distinguishes it from historical price or constituent tools like stock_zh_index_hist_csindex and index_stock_cons_csindex. However, it lacks an explicit verb like 'fetch' or 'retrieve', so it reads more as a data label than a clear action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 alternative index-related tools. It does not mention any specific use cases, prerequisites, or situations where this tool is preferred. Sibling tools exist for historical prices, constituents, and spot data, but no exclusions or alternatives are noted.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds minimal behavioral context, only mentioning that the return is a pandas.DataFrame. It does not disclose any data freshness, pagination, or potential quirks beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title, but includes a long URL that adds little value for an AI agent. It is not bloated, and the docstring-style parameter/return lines are structured clearly, though they could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 should clarify the symbol format, supported markets (e.g., A-shares vs HK), and what the returned DataFrame contains. It only says '估值比较' without explaining the output columns or any limitations. The 'zh' in the tool name suggests A-shares, but the description does not confirm this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with no description, and schema description coverage is 0%. The description only says 'param symbol: 股票代码' (stock code), which is tautological with the parameter name. The default value 'SZ000895' hints at an exchange prefix format, but this is not explicitly explained, leaving ambiguity about the expected symbol format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description gives the full path '东方财富-行情中心-同行比较-估值比较' (Eastmoney - Market Center - Peer Comparison - Valuation Comparison), which clearly identifies the data source and resource. It distinguishes from sibling tools like stock_zh_scale_comparison_em by specifying '估值比较' (valuation comparison), but lacks an explicit verb such as 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for obtaining valuation comparison data for a stock, but it does not explicitly state when to use it versus alternatives like stock_hk_valuation_comparison_em or stock_zh_valuation_baidu. No exclusions or alternative guidance is 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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type but no additional behavioral context (e.g., data freshness, empty results, or format assumptions). It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title, includes the source URL, and uses a clear docstring-style format. It avoids unnecessary verbosity, though the title and return line are somewhat redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only repeats the tool name for the return value ('昨日涨停股池') without describing the DataFrame's columns or content. The ambiguity between the 'date' parameter and the word 'previous' is unresolved, leaving the agent uncertain about what data to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for 'date', so the description's ':param date: 交易日' and ':type date: str' provide basic meaning. However, it lacks specifics on the expected format (though the default suggests YYYYMMDD) and the relationship between the given date and the 'previous' day, which is a key semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves '昨日涨停股池' (yesterday's limit-up stock pool) from East Money, which is a specific resource. However, it does not explicitly differentiate itself from the many sibling stock_zt_pool_* tools, though the name 'previous' hints at the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the numerous sibling limit-up pool tools (e.g., stock_zt_pool_em, stock_zt_pool_strong_em). The description only mentions a date parameter but does not explain the intended context 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame) but no additional behavioral traits such as rate limits, data scope, or network dependencies. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only a title, URL, and return type. It is front-loaded and has no fluff. However, it reads more like a docstring fragment than a coherent description, but it earns its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, no-parameter tool with good annotations, the description is adequate but lacks detail about the returned data structure. It only states '分类' (classification) and pandas.DataFrame, leaving the agent unaware of specific columns or content. This is a minimal but acceptable description for a simple classification listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema fully covers parameter semantics. Per the rubric, a 0-parameter tool gets a baseline of 4, and the description does not need to add any parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '乐咕乐股-申万一级-分类' (LeGuLeGu Shenwan Level 1 Classification) and provides the exact URL. The tool name also reinforces the purpose. However, it lacks an explicit verb like 'retrieves' and does not directly distinguish itself from sibling tools within 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/5Does 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, no prerequisites, and no exclusions. It only states the source and return type, leaving the agent to infer 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds only a source URL and return type, which does not disclose any additional behavioral traits (e.g., data freshness, pagination, rate limits). No contradiction with annotations, but minimal added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three lines), but it largely repeats the title and provides only a URL plus return type. It is not overly verbose, but the information is somewhat sparse and the URL may be of limited use to an agent. It is front-loaded with the title, yet the lack of any substantive explanation makes it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description provides the essential facts: source (Endata), resource type (TV series), and return format (pandas.DataFrame). For a simple data retrieval tool, this is largely sufficient. However, it does not specify what fields or granularity the data contains, which could be useful but is not critical for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete. According to the rubric, a baseline of 4 is appropriate for 0-parameter tools. The description's return type adds slight clarity but is not required for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning 电视剧集 (TV series) data from the 艺恩 (Endata) platform, with a URL and return type. While the description is essentially a title plus return annotation, it is specific enough to distinguish it from video_variety_show (variety shows) and other media tools. However, it lacks a directive verb like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions. The context of 'video_tv' versus 'video_variety_show' implies usage, but the description itself does not state that this is for TV series data retrieval or when to prefer it over other 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and a source URL, but no extra behavioral context such as pagination, rate limits, or data update frequency. No 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat cluttered, mixing a title, a URL, and a docstring-style return type in a single block. It is not front-loaded with a clear 'what' statement and includes redundant elements (e.g., the URL), but it remains relatively short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description conveys the data source and return type reasonably well. However, it does not clarify the exact data scope (e.g., all sub-funds, any filtering) or explicitly contrast with sibling fund tools, leaving some ambiguity for an agent deciding if this tool fits a query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. According to the rubric, the baseline for 0 parameters is 4, and the description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '证券公司私募投资基金' (securities company private equity funds) from the AMAC information disclosure platform. Although it lacks an explicit action verb, the source URL and ':return' imply data retrieval, and the specific fund type distinguishes it from sibling amac_* 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/5Does 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 are many similar amac_* tools (e.g., amac_fund_info, amac_member_sub_info), but the description does not explain how this tool differs or when it is the appropriate choice.
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 already disclose readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), but no additional behavioral details such as pagination, data limits, or freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the title, followed by a useful URL and return type. It has no redundant content, but could be slightly improved with a proper explanatory sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 what the returned DataFrame contains (e.g., columns, scope). It only repeats the title and return type, leaving the data structure and the 'comprehensive' nature ambiguous. More context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly implies a no-input comprehensive query and does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource and action: '私募基金管理人综合查询' (comprehensive query of private fund managers) from the AMAC website, with a URL and return type. It is specific and distinguishes itself from sibling tools by its focus on manager info, though it lacks an explicit verb and doesn't compare with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other AMAC tools like amac_manager_cancelled_info or amac_member_info. The description only states what it is, not when to prefer it, and no alternatives or exclusions 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?
Annotations already cover read-only, non-destructive, and idempotent behavior. The description adds the return type (pandas.DataFrame) and the source URL, which is useful, but it does not disclose other behaviors like network requirements or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but somewhat repetitive, repeating the same phrase in the title and the :return: section. It lacks a clear front-loaded summary and the URL placeholder between the title and return value adds clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description provides enough context to understand the general data source, it lacks details about the DataFrame columns or the exact structure of the return. Given no output schema, the description could better explain what data is included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input space. The description correctly avoids discussing parameters, aligning with the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific resource: information disclosure for securities companies' private fund subsidiary managers from AMAC. It distinguishes from sibling tools like amac_member_info by the precise entity type, though it lacks an explicit verb like 'query' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or compare with other AMAC tools, leaving the agent to infer usage from the name and content alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds the source URL and return type but does not disclose additional behavioral traits such as data freshness, pagination, or any limitations beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with one line of source context and a short docstring for parameters and return. It is not overly verbose, though the placement of the URL in the first line slightly affects readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential source and return type. However, it lacks details on the exact contents of the returned DataFrame, expected date format, and any edge cases, making it minimally acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides the parameter 'date' with type str and a brief Chinese description '指定日期' (specified date), which adds some meaning. However, it does not specify the expected date format (e.g., YYYYMMDD), though the default value '20210111' hints at it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing bond cash market overview data from SSE, with the return type '债券成交概览' (bond transaction overview). It distinguishes itself from sibling tools by specifying the SSE source and the specific overview data, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only gives a source URL and parameter documentation, without mentioning exclusions, prerequisites, or scenarios where other bond 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, lowering the bar. The description adds the source URL, return type (pandas.DataFrame), and the one-month date constraint. It doesn't reveal much about data structure, availability, or potential quirks, but it doesn't contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not concise: it repeats the title, includes a URL, and has a poorly interleaved docstring with a type line out of place. While not excessively long, the structure is messy and not front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return structure, but it only says the return is historical data and a pandas.DataFrame without specifying columns. The symbol parameter is vague ('the indicator to fetch') with no list of valid values, and the date format is implied only by the default value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides a docstring explaining each parameter: symbol (indicator to fetch), period (term interval with allowed values {'0.1','0.5','1'}), and start/end dates with a one-month range limit. The malformed docstring and lack of explicit date format prevent a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides historical closing yield curve data (收盘收益率曲线历史数据) and includes a source URL. However, it is a noun phrase rather than a verb+resource, and it doesn't explicitly distinguish from closely related sibling tools like bond_china_close_return_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching historical closing yield curve data from Chinamoney, and it mentions a date-range constraint (no more than 1 month). However, it provides no explicit guidance on when to choose this tool over sibling tools such as bond_china_close_return_map or bond_china_yield.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and the source URL, but does not describe output structure or any edge cases. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description mixes a long Chinese title, a URL, and docstring-style parameter/return fields. It is somewhat redundant (the phrase 查询相关指标的参数 appears both in the header and the return description). The structure is acceptable but not tightly organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the basic function and parameter choices. However, it does not explain what the returned DataFrame contains or how the output might be used in conjunction with other bond tools. The behavior is simple enough that this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly lists the valid choices for symbol: {主承销商, 债券类型, 息票类型, 发行年份, 评级等级}, which is critical since the schema has no enums. It does not explain the meaning of each indicator or output format beyond the names, but the choices are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool queries parameters for indicators from China Foreign Exchange Trade System (中国外汇交易中心暨全国银行间同业拆借中心). The listed symbol choices (主承销商, 债券类型, etc.) clarify what kinds of parameters are returned. It is fairly specific but could be clearer that it is a helper for retrieving valid index parameter values, and the Chinese-language title may be less informative for non-Chinese users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention that it can be used to obtain valid symbol values for sibling tools like bond_info_cm or bond_info_detail_cm. The URL provides a source but not usage context.
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 already indicate this is a read-only, idempotent, non-destructive operation. The description adds that it returns a pandas.DataFrame and provides the source URL, but it does not describe the actual data contents, potential pagination, or any other behavioral details. This adds some context beyond annotations but remains limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, containing only essential information: the source URL, the data category, and the parameter/return types. Each line serves a purpose, though the formatting is a bit fragmentary with newlines separating different elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a one-parameter read-only tool with no output schema. The description says it returns a pandas.DataFrame but does not specify the columns or the structure of the DataFrame. It also lacks examples of expected output or any caveats. Given the minimal schema and no output schema, the description should provide more detail about the return value to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a 'symbol' parameter with a default value and no description. The description adds meaning by explaining that symbol is the convertible bond code (可转债代码) and gives an example URL with a specific code (113527). This compensates for the 0% schema coverage and clarifies the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool performs convertible bond value analysis (可转债价值分析) and specifically references premium rate analysis (溢价率分析). The name and description are specific enough to distinguish it from sibling tools like bond_zh_cov_info, though it doesn't explicitly contrast 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/5Does 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 expected use cases, prerequisites, or situations where a different bond analysis tool would be more appropriate. The description only provides a URL and a function signature.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data source URL and a pandas.DataFrame return type, but it does not disclose behaviors such as data availability windows, required symbol format, or potential failure modes. This is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured as a docstring: source, URL, parameters, return type. It wastes no words and is appropriately sized for a one-parameter data-fetch tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description provides the essential context: source, symbol parameter meaning, and return type (pandas DataFrame). It does lack detail on the DataFrame's columns or whether 'pre-market' is a fixed session, but given the tool's simplicity and no output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description must compensate for the schema's lack of parameter meaning. It describes symbol as '转债代码' (convertible bond code), which gives a minimal semantic, and the example URL hints at a format, but it does not specify the expected exchange-prefixed format (e.g., 'sh113570') or the range of valid symbols. This is only marginal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool fetches pre-market time-share quotes for Chinese convertible bonds from Eastmoney, using the phrase '东方财富网-可转债-分时行情-盘前'. This clearly identifies the resource and scope, but it does not explicitly compare with the closely-related siblings bond_zh_hs_cov_min or bond_zh_hs_cov_spot, so the differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 contains only a source URL and parameter documentation, with no mention of when the pre-market variant is appropriate or when to use the regular/min/spot/daily sibling tools instead.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source and return type, but does not disclose rate limits, pagination, or column structure. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring-style block with title, URL, parameters, and return type. It is front-loaded and efficient, though the long URL may be unnecessary for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with 3 parameters and no output schema, the description covers parameter meanings and return type. However, it lacks date format clarification, column-level return details, and usage context relative to sibling tools, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the main source of parameter meaning. It explains symbol as a choice of currencies and start_date/end_date as trading days, and mentions the DataFrame return. However, it does not specify the expected date format clearly; the URL example uses dashes while schema defaults use compact digits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a historical data query for Bank of China RMB exchange rates via Sina Finance, with a specific URL and parameter list. It specifies the resource and action, but does not explicitly differentiate from sibling currency tools like currency_boc_safe or currency_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 it does, not when it should be preferred over the many sibling currency/forex 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?
Annotations already declare the tool as safe, read-only, idempotent, and non-destructive. The description adds the source URL and daily frequency (每日行情数据), providing some behavioral context beyond annotations. However, it does not disclose data freshness, time range, or caveats about the underlying source, so the added value is minimal but not absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and uses a conventional docstring format with :return: and :rtype:. The URL is useful. However, the title is duplicated from the annotations, which adds minimal redundancy. Overall, it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return value. It only says '国内碳情每日行情数据' (domestic carbon daily market data), which is vague. It does not specify what fields or columns the DataFrame contains, nor whether it covers a specific date or a historical range. For a tool with no parameters, the default behavior should be more explicitly documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The empty schema fully defines the interface, and the description does not need to add parameter details. The baseline of 4 is appropriate given the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Shenzhen Carbon Emissions Exchange) and the data type (domestic carbon daily market data), distinguishing it from regional siblings like energy_carbon_bj and energy_carbon_gz. The return line reinforces that it provides daily quotes as a DataFrame, making the purpose unmistakable despite the lack of an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 energy_carbon_bj, energy_carbon_gz, or energy_carbon_domestic. The only differentiation is the exchange name in the title, but there is no explicit when-to-use or alternative naming, leaving the agent to infer selection based on the tool name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and source URLs but does not disclose additional behavioral traits like network dependence or data formatting specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and avoids unnecessary fluff, but the two URL lines and the wildcard token add noise without clear purpose. The layout is a docstring fragment rather than a clean, agent-oriented description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 gives source URLs and return type, but it does not specify the DataFrame's columns or how the symbol maps to specific Forbes lists. The ambiguous wildcard and lack of output schema leave a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents the symbol parameter with example choices but includes an ambiguous '*' wildcard that is never explained. The schema's default value '2021福布斯中国创投人100' is not among the listed choices, creating confusion. It provides partial compensation for the 0% schema coverage but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 福布斯中国-榜单 with source URLs, and the return type indicates it fetches list data. However, it lacks an explicit verb like '获取' or '返回', and differentiation from similar ranking tools (e.g., hurun_rank) relies on the brand name rather than a stated 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/5Does 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 hurun_rank or xincaifu_rank. The description only lists parameter choices and return type, with no contextual usage instructions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the source URL and return type (pandas.DataFrame) but doesn't disclose additional behavioral traits like pagination, rate limits, or data update frequency. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description mixes English and Chinese, includes a long source path and URL, and uses structured tags (:param, :return). It's readable but somewhat verbose and redundant with the title. The key info is present, but the structure could be more concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers the data source, return type, and parameter meaning. However, it lacks usage alternatives, any mention of data coverage or limitations, and doesn't explain what the returned announcement list contains in detail. It's minimally complete but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with a default, with no description in the schema. The tool description compensates by explaining that symbol is the fund code and can be obtained via ak.fund_name_em(). This adds meaningful semantics beyond the schema, though it doesn't specify format examples or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches dividend distribution announcements from East Money's Tiantian Fund website, with the specific category '分红配送' in the name and text. It distinguishes itself from sibling announcement tools like fund_announcement_personnel_em and fund_announcement_report_em by specifying the dividend type, 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 Guidelines2/5Does 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 other announcement tools. It does mention how to obtain the symbol parameter via ak.fund_name_em(), but that's parameter context rather than usage guidance. There's no indication of prerequisites, expected use cases, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the return is a pandas.DataFrame and includes the source URL, but does not disclose additional behavioral traits such as rate limits, authentication needs, or specifics about what the trading rules data contains. Since annotations cover the safety profile, 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but structured as a docstring with a bare sample URL (https://danjuanfunds.com/djapi/fund/detail/675091) that is not explained. It would be improved by front-loading a clear purpose statement rather than leading with the title and URL. No unnecessary fluff, but the structure is somewhat mechanical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the return type and source, which is useful, but it does not describe the content of the trading rules, which fund codes are supported, or any edge cases. With no output schema and many sibling fund tools, a bit more context would help, but the tool is simple and annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides docstrings for both parameters: symbol is '基金代码' (fund code) and timeout is described as 'choice of None or a positive float number'. This adds meaning beyond the raw schema, especially for symbol. The timeout semantics are minimal but still more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves trading rules (交易规则) for a fund, with the title '雪球基金-交易规则' and the return type. It distinguishes among sibling fund_individual_*_xq tools by focusing on trading rules rather than basic info or holdings. However, it lacks an explicit verb like 'get' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools like fund_individual_basic_info_xq or fund_individual_detail_hold_xq, nor any exclusions or prerequisites. The only context is a bare sample URL.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, which fully cover the safety profile. The description adds the return type (pandas.DataFrame) and the data source URL, but no additional behavioral traits such as update frequency or historical coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes key details (title, URL, return type, data source). It is structured but lacks a substantive summary of what the data represents. It is not overly verbose, but the content is somewhat minimal and boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of explaining the return value. It states the return type (pandas.DataFrame) but does not describe the structure, columns, or time range. Given the tool's simplicity, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. Schema coverage is 100% (empty properties), making the schema fully sufficient. The description's mention of the return type adds useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (fund positions for flexible allocation funds) and the data source (乐咕乐股 with a specific URL). The verb is implied as retrieval. It distinguishes from siblings like fund_balance_position_lg and fund_stock_position_lg, which target different fund 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool compared to other fund position tools. It does not state when this tool is preferred or mention any exclusions. The description only provides a data source and return type.
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 already fully cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lower. The description adds the data-source URL and DataFrame return type, which are useful, but it does not disclose the data contents, whether the ranking is current or historical, or any caveats about the returned DataFrame. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at four short lines, but it is a docstring dump rather than agent-oriented prose. The first line duplicates the annotation title, and the :return:/:rtype: scaffolding is Python-docstring convention rather than structured guidance. It is concise but not fully optimized for the structured information already available.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description is minimally viable: it names the source and the return type. However, with no output schema present, the description carries the burden of explaining the output, and it omits what columns the DataFrame contains, whether all money-market funds are returned, and whether the ranking is point-in-time or time-series. It is adequate but thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing for the description to explain; per the rubric, 0 parameters earns a baseline of 4. The description does not mislead about parameters and its return-type note is consistent with the schema's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource: money market fund rankings (货币型基金排行) from the Eastmoney data center, with an exact URL pointing to the ranking page and a stated output type (pandas.DataFrame). It is clear and self-contained, though it is phrased as a noun/title rather than an explicit verb+resource statement, and it does not explicitly contrast against sibling rank tools like fund_open_fund_rank_em or fund_fh_rank_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Given the large family of fund-ranking siblings (fund_money_fund_daily_em, fund_fh_rank_em, fund_lcx_rank_em, fund_open_fund_rank_em), an agent receives no direction for selecting this specific ranking tool. There are no exclusions, prerequisites, or 'use X instead' hints.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context: the data source (东方财富网-天天基金网), the URL, and the return type (pandas.DataFrame). However, it does not disclose any additional behavioral traits such as pagination, rate limits, or specifics about what data the returned DataFrame contains, so it provides only modest added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the purpose and source URL front-loaded, followed by clear parameter docstrings and return type. Each line serves a purpose; no fluff. The only minor issue is that the title line is repeated verbatim in the annotations' title field, but that doesn't dilute the description itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With good annotations and no output schema, the description provides enough for basic usage but has clear gaps: the set of valid indicator values is absent, and the returned DataFrame structure is not described. It explains the source and period options but leaves the most important parameter (indicator) vague, making the tool's capabilities less predictable than they could be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry parameter meaning. It explains symbol (基金代码 with a way to obtain all codes) and period (with an explicit choice list). However, indicator is only described as '需要获取的指标' (the indicator to fetch), which is tautological and gives no list of valid values or examples. This leaves a key parameter under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches open-end fund net value data from 天天基金网 (East Money), with a specific URL and resource. It describes the action as returning data for a specified fund and indicator. However, it doesn't explicitly distinguish itself from closely related sibling tools like fund_open_fund_daily_em or fund_open_fund_rank_em, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative fund data tools. It only mentions that the symbol can be obtained by calling ak.fund_open_fund_daily_em(), which is a prerequisite rather than a usage guideline. There are no exclusions or alternative tool references.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) but does not disclose additional behavioral details like pagination, rate limits, or data granularity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and organized as title, URL, param, and return. It front-loads the key information and avoids verbosity, though it is slightly sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 provides the return type but does not explain what fields are included in the '基本概况' (basic overview). This is a gap for users expecting to know the DataFrame columns, but the tool is simple and self-descriptive from the name and URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description defines the parameter as '基金代码' (fund code), which adds basic meaning. It does not elaborate on format, constraints, or examples beyond the default '015641' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '天天基金-基金档案-基本概况' (Tiantian Fund - Fund Archive - Basic Overview) and provides a URL, clearly indicating it retrieves basic fund overview information. However, it does not distinguish this tool from many sibling fund tools (e.g., fund_info_ths, fund_individual_basic_info_xq) 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/5Does 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 only gives a parameter and return type, with no context about selecting this tool among the numerous fund-related siblings.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds context about the 'date' parameter behavior (empty string returns latest available year) and return type (DataFrame), but does not disclose potential network dependencies, data source limitations, or column details that might affect usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with source, URL, and param/return documentation. It is front-loaded with the source name and URL, and every line serves a purpose. Some might argue the Chinese is terse, but it is efficient and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description needs to explain the return value more thoroughly. It only says '基金持仓' and 'pandas.DataFrame' without detailing columns or types. Given the potential complexity of fund holding data (e.g., stock names, percentages, market values), this is insufficient for an agent to fully understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well. It explains that 'symbol' is a fund code and 'date' is a query year, with a special behavior for empty string. This adds meaningful semantics beyond the raw schema, which only provides types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: fund holdings (基金持仓) from Eastmoney's fund archive investment portfolio page, with a specific URL. The verb is implied (query/fetch) and the scope is 'fund holdings' which distinguishes it from bond holdings or industry allocation siblings, though it doesn't explicitly say 'stock' holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that this is for stock holdings as opposed to fund_portfolio_bond_hold_em or fund_portfolio_industry_allocation_em, nor does it suggest any exclusions or complementary tools. The only usage hint is the parameter explanation.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that the return is a pandas DataFrame and shows a Sina URL, offering source context, but it does not disclose additional behavior such as output columns or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose. The embedded docstring and URL slightly reduce clarity, but the overall structure is acceptable for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should ideally describe return fields, but it only states the return is a 'pandas.DataFrame' of futures contract details. The example URL adds some context, yet the actual columns and data content remain unspecified, leaving a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for 'symbol' (0% coverage). The description calls it '合约' (contract) and includes an example URL with 'V2101', but it does not explain expected formats like the default 'AP2101' or exchange-specific prefixes, providing only minimal compensation for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查询期货合约详情' (query futures contract details), providing a specific verb and resource. However, it does not differentiate from the similarly named sibling tool 'futures_contract_detail_em', so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like futures_contract_detail_em or futures_contract_info_*. The Sina URL hints at a data source, but this is not stated as a selection criterion.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description additionally reveals the source URL and navigation path, which is useful context. However, it does not disclose potential failure modes, data formatting, or rate limits, but the bar is lowered due to annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and includes key elements: source URL, navigation note, parameter, and return type. The navigation steps are somewhat unnecessary for API usage but do not bloat the text. It is appropriately sized, though the '年月日' inconsistency should be fixed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read-only tool, and no output schema exists. The description provides a source URL and return type but does not describe the DataFrame columns or content beyond '交割情况表'. It also leaves ambiguity about the exact date format, which is critical for correct invocation. Given the low complexity, the description is moderately complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'date' parameter (coverage 0%), so the description must compensate. It says ':param date: 年月日' (year month day), but the default value is '202312' which is year-month format, not year-month-day. This is inconsistent and potentially misleading, though it does indicate the date parameter exists and has a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning the Shanghai Futures Exchange delivery situation table, which is a clear resource. Although it lacks an explicit verb like 'fetch' or 'download', the return statement makes the purpose evident. It is distinguishable from sibling delivery tools for other exchanges (e.g., futures_delivery_czce) by the SHFE name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides navigation context (date -> monthly statistics -> dropdown) and notes that the parameter is a date, implying monthly usage. However, it does not explicitly state when to use this tool over siblings like futures_delivery_czce or futures_settle_shfe, nor does it give exclusions. The usage 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (DataFrame), which are useful but not deep behavioral traits like refresh frequency, pagination, or data coverage. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured docstring format, but is somewhat redundant: '玄田数据-供应维度' appears in both the purpose and the return description, adding no new information. The return type information is useful, and the parameter list is necessary, but the overall structure could be tightened with a clearer upfront statement of the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and rich annotations, the tool is relatively simple. The description provides the parameter choices, return type, and source URL. However, with no output schema, it does not describe the specific columns or units of the returned DataFrame, and it fails to differentiate from siblings. It is minimally complete but leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and no enum is defined in the schema, so the description's explicit list of allowed values for the 'symbol' parameter is critical. It provides a clear enumeration of options, which helps an agent invoke the tool correctly. It does not explain what each symbol represents semantically, but the names are reasonably descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource ('supply dimension' data from 玄田数据) and indicates the return type (pandas.DataFrame) and parameter choices. While there is no explicit verb like 'fetch' or 'list', the intent is clearly data retrieval. It does not, however, distinguish this tool from the many sibling hog-related 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/5Does 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, prerequisites, or scenarios where a sibling tool (e.g., futures_hog_core, spot_hog_soozhu) would be more appropriate. Usage context is only implicit via the parameter choices.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the source URL and the dependency on another function for symbol, but does not disclose behavioral traits such as date format expectations, column contents, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring format with title, URL, param/type/return lines. It is not overly verbose, though the URL and repetitive type annotations add little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain return values. It states that the return is a pandas DataFrame of main continuous daily data but does not list columns or describe the data structure. The date format ambiguity and symbol source dependency are also not fully resolved, making the description minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It gives minimal guidance: symbol should be obtained from futures_display_main_sina, and start_date/end_date are '开始时间'/'结束时间' (start/end times). However, it fails to specify the date format (e.g., YYYYMMDD) or provide examples, leaving the agent to infer from defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as Sina Finance futures main continuous daily data (新浪财经-期货-主力连续日数据) and reiterates the return value as 主力连续日数据. It distinguishes itself from many siblings by emphasizing 'main continuous' (主力连续), though it lacks an explicit verb like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a useful usage hint by instructing users to obtain the symbol via ak.futures_display_main_sina(). However, it does not explicitly state when to use this tool versus alternative futures data tools (e.g., futures_zh_daily_sina) or mention any prerequisites or date range constraints.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which provides some context, but it does not explain data freshness, structure, or any other behavioral traits beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes a useful source URL and return type, but it is somewhat redundant: the phrase '期货的品种和代码映射' appears both in the main description and in the :return line. It is not front-loaded with an action verb and is presented as unformatted Chinese text, though it is still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description does specify the return type as DataFrame, which is helpful. However, it lacks details about the mapping's columns, format, or how it relates to other futures tools, leaving some ambiguity about the exact output and use case. For a simple parameterless mapping tool, this is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description correctly does not attempt to explain parameters because there are none, and the empty schema is fully descriptive in that regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides a mapping of futures varieties and codes ('期货的品种和代码映射'), which is a specific resource and clearly distinguishes it as a symbol/name mapping tool. However, it lacks an explicit verb like 'get' or 'fetch' and is phrased as a noun phrase, making it slightly weaker than a clear action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools such as futures_comm_info or futures_contract_info. There is no mention of prerequisites, contexts, or alternative tools, leaving the agent to infer usage solely from the name and description.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds some context beyond annotations: the data source URL, the start date 20100416, and the return type as pandas.DataFrame. However, it does not disclose potential rate limits, error handling, or response details beyond the start date.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring format is structured with separate param/return sections and a source URL, with minimal redundancy. The title is repeated in the first line, but overall it is compact and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description covers the source, start date, and return type, which is adequate for basic use. However, it does not describe the columns or contents of the returned DataFrame, nor does it mention whether the date is optional despite the schema default. Given the annotations and simplicity, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'date' parameter (0% coverage), so the description must compensate. It explains that date is a trading day and that data begins on 20100416, providing some semantics. However, it does not explicitly state the required format (e.g., YYYYMMDD) or behavior for invalid dates, only implying format through the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the tool as providing China Financial Futures Exchange (CFFEX) daily-frequency trading data, with a source URL and return type. While it lacks an explicit verb, the tool name 'get_cffex_daily' and the Chinese title make the purpose clear and distinguish it from siblings such as get_cffex_rank_table and futures_settle_cffex.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like get_cffex_rank_table or futures_settle_cffex. The description only states what data it returns, leaving the agent to infer usage from the name and title, with 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL (http://www.cnindex.com.cn/module/index-detail.html) and confirms the return type (pandas.DataFrame), but it does not disclose behavioral traits such as date ranges, data columns, or any limitations. Since annotations carry the safety burden, this is adequate but not rich in 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and contains no fluff: a title line, a reference URL, and a concise docstring with param/return/type. Every sentence serves a purpose, though the title and first docstring line are somewhat redundant. It is well under the size limit and front-loaded with the key term '历史调样'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and no output schema, the description is sufficient for basic invocation but lacks details about the returned DataFrame structure (columns, index, date range) and any pagination or filtering options. The annotations cover safety and idempotency, but a user would still wonder what historical adjustment data looks like in practice. For a simple tool, this is a minimum viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a single string parameter 'symbol' with default '399005' and no description. The description's docstring clarifies that 'symbol' is the 指数代码 (index code), adding semantic meaning beyond the bare schema. However, it does not explain accepted formats (e.g., 6-digit code vs. full prefix) or the meaning of the default value, leaving some ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves '历史调样' (historical sample adjustments) for the 国证指数 (CNI Index), and the docstring clarifies it returns a pandas DataFrame with that data. It is specific about the resource (index samples) and the operation (historical adjustment retrieval), though the title is a noun phrase rather than an action verb. It does not explicitly differentiate from sibling tools like index_detail_cni, but the name and description make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 index_detail_cni might be for current sample details or that index_hist_cni covers historical index values, nor does it state any exclusions or prerequisites. The URL and docstring imply usage for a single index code, but there is no explicit context on selecting this over sibling 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that the return type is a pandas.DataFrame and provides the source URL, which is some added context. However, it does not disclose data structure, time range, or potential scraping limitations, so it remains modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with the source URL, return description, and return type. The first line repeats the annotation title, which is mildly redundant, but overall it is economical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is too thin. It doesn't explain what columns or index values are returned, whether the data is historical or current, or any interpretation of the index. Even with the DataFrame return type noted, the agent lacks essential context to understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully self-descriptive. According to the rubric, a baseline of 4 is appropriate; no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns the pig market price index (生猪市场价格指数) from 行情宝 and provides a source URL. This identifies the specific resource, though the verb is implied via ':return:' rather than explicit. It does not distinguish from sibling tools like spot_hog_soozhu, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative hog price or index tools. There is no mention of prerequisites, scenarios, or exclusions, so the agent receives no directional help.
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 already mark readOnlyHint=true and idempotentHint=true, so the safe, read-only nature is known. The description adds the return type and source URL, but lacks further behavioral details such as pagination, data update frequency, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a short title line, source URL, and standardized :param:/:return: tags. No redundant or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with rich annotations, the description provides the parameter choices, return type, and source URL, covering the essential invocation needs. The lack of an output schema is partially mitigated by the explicit DataFrame return type, though column details are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the symbol parameter, but the description provides an exhaustive list of valid choices and its type, which is essential for correct invocation. The meanings are not elaborated beyond the names, but the names are largely self-explanatory, making this a strong compensation for the zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '柯桥时尚指数及其子项数据' indicating it returns the Keqiao Fashion Index and its sub-item data, with a source URL and DataFrame return type. However, there is no explicit verb like 'fetch' or 'retrieve', and it does not differentiate from sibling index tools such as index_kq_fz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative index tools. The description lists parameter options and the data source but gives no context for selection 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?
The description adds that the return is a pandas.DataFrame and includes the source URL, but no further behavioral details such as data range, update frequency, or potential quirks. Annotations already declare this as a safe read-only operation, so the added value is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only a title, a source URL, and a return type declaration. Every segment serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description should explain the returned data more thoroughly. It only states 'labor input index' without detailing columns, historical range, or how it differs from similarly named sibling tools. This is insufficient for an agent to know exactly what data it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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's mention of return type does not relate to parameter semantics, and there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the 'labor input index' from Caixin Data's index report, with a source URL. It is specific about the resource, but does not explicitly distinguish it from sibling index tools like index_nei_cx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other index tools. The description merely states what it is, leaving the agent to infer usage entirely from the name.
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 already declare the tool as readOnly, idempotent, openWorld, and non-destructive. The description adds a source URL and return type (pandas.DataFrame), but discloses no other behavioral details such as data frequency, period covered, or potential request limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant, repeating the same Chinese phrase for the tool name and the return description. It includes a URL that may be useful but not essential. The structure is functional yet could be more concise by removing duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description identifies the data source (QVIX for 100ETF) and period type (intraday), and specifies the return type as pandas.DataFrame. It does not detail the columns or update frequency, but for a simple data-fetch tool this is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. There are no parameters to explain, and the description appropriately avoids adding unnecessary parameter details. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the resource: Shenzhen 100ETF options volatility index QVIX intraday (深证100ETF 期权波动率指数 QVIX-分时). This distinguishes it from daily QVIX tools by including '分时' and the 'min' in the tool name. However, it lacks an explicit verb (e.g., 'retrieve'), relying on the implicit return statement to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling QVIX tools (e.g., index_option_100etf_qvix, index_option_300etf_min_qvix). There is no mention of use cases, exclusions, or alternatives.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type but does not disclose data availability, latency, or limitations. For a zero-parameter read-only tool, this is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first line duplicates the title, and the `:return:` line repeats the same phrase. The URL is useful, but the repetitive structure wastes space that could have provided additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter data access tool, the description gives the return type and source, but lacks any detail about the DataFrame contents, time range, frequency, or usage context. Given the many sibling QVIX tools, this minimal description may leave an agent uncertain about what distinguishes this tool from the daily version.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter behavior to explain. The description adds no parameters beyond the schema, but with zero params this is acceptable; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact resource: '300 ETF 期权波动率指数 QVIX-分时' (300 ETF option volatility index QVIX intraday) and the `:return:` line clarifies it returns this data as a pandas DataFrame. However, it lacks an explicit verb like 'fetches' or 'retrieves,' so the action is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools like `index_option_300etf_qvix` (the non-minute version) or other QVIX variants. There are no exclusions, alternatives, or contextual triggers 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and a source URL, but doesn't disclose behavioral nuances like data frequency, columns, or potential delays. It doesn't contradict annotations, so a baseline score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to-the-point, but it's repetitive (the same Chinese phrase appears twice) and includes a raw URL without context. It's not well-structured, mixing the title, URL, and docstring-style returns. It earns a middling score because it's compact but inefficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter data retrieval tool, the description provides the essential information: what it returns (a DataFrame) and a source. However, it doesn't describe the DataFrame's contents or columns, and with no output schema, that's a gap. The annotations cover the read-only aspect, but the description could be more complete about the data's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description doesn't need to explain parameter semantics; there are none. It does specify the return type, which adds minimal value beyond the schema. No parameter documentation is required here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: the QVIX (volatility index) for CSI 300 index options. It uses a specific noun phrase and provides a source URL, making the tool's purpose intelligible. However, it lacks an explicit verb like 'get' or 'fetch', and doesn't distinguish itself from similarly named siblings such as index_option_300etf_qvix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs. alternatives. The description doesn't mention that this is specifically for the CSI 300 index options (as opposed to ETF options or other index options) or any selection criteria. It simply states what it is without usage context.
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 already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the source URL and return type (pandas.DataFrame) but no additional behavioral traits like data delay, update frequency, or coverage limits. The description does not contradict the annotations, and given the annotation coverage, a mid-level score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but repetitive: the title '500 ETF 期权波动率指数 QVIX-分时' appears twice, in the first line and again in the ':return:' line. The URL and rtype lines add some value, but the redundancy suggests inefficient structure. It is still short and not verbose, so it avoids the lowest scores.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter intraday index tool, the description names the data (QVIX for 500 ETF options) and the return type (pandas.DataFrame), but it does not specify columns, frequency, or any caveats. Since there is no output schema, the description carries the burden of explaining what to expect, and it falls short of fully doing so. The tool's simplicity makes it minimally adequate, but there are clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with zero parameters, so schema coverage is trivially 100%. The description has no parameter-related responsibilities; the baseline for zero parameters is 4, and the description does not need to explain anything further. No parameter confusion exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning the 500 ETF options volatility index QVIX in intraday (分时) form, which matches the tool name's 'min' prefix and distinguishes it from the daily sibling index_option_500etf_qvix. However, it lacks an explicit verb (e.g., '获取' or '查询') and reads as a noun phrase with a URL and return type, so it is clear but not maximally 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/5Does 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 such as the daily QVIX tool (index_option_500etf_qvix) or other underlying indices (e.g., 300etf, 50etf). The description does not mention any conditions, exclusions, or comparative context, leaving the agent without selection criteria beyond the name.
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 already declare the operation as read-only, idempotent, and non-destructive. The description adds the return type (pandas.DataFrame) and a source URL, providing some behavioral context beyond the annotations, but it does not disclose response structure, data frequency, or potential limitations such as missing historical data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the essential information, but it redundantly repeats the same phrase multiple times (title, description, return, rtype). This repetition wastes a sentence but the overall length remains acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter data retrieval tool, the description provides the core information (what data and return type) and a reference URL. However, it lacks details about the DataFrame's columns, date range, or whether it returns historical or current data, leaving some ambiguity despite the annotations indicating a safe read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool accepts zero parameters, so the empty schema requires no explanation. The description correctly notes the return type but adds no parameter semantics, which is appropriate given the absence of parameters. The baseline of 4 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data as the SSE 50 Stock Index Option Volatility Index (QVIX) with a source URL, making the tool's purpose understandable. It distinguishes from sibling tools that target other underlyings (e.g., 50etf) through the explicit '50index' designation, though it does not clarify the daily vs. minute granularity offered by sibling 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/5Does 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 alternative QVIX tools (e.g., index_option_50index_min_qvix or index_option_50etf_qvix). The description only states what data is returned, not the selection criteria, prerequisites, or scenarios where this tool is preferred.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a source URL and return type, but does not disclose behavioral details such as data granularity, update frequency, or any quirks. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: the phrase '创业板 期权波动率指数 QVIX-分时' appears in both the main text and the :return: docstring. The URL adds useful context, but the repetition wastes space and the structure is a raw docstring rather than a clean summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain return values. It states the return type (pandas.DataFrame) and the data source URL, but it does not describe the columns, time index, or data interval, leaving the agent to guess the structure. While the tool is simple, more detail about the DataFrame content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already exhaustively covers inputs. The description adds no parameter information, which is appropriate; with 0 params, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the ChiNext (创业板) options volatility index QVIX minute data, which is specific and distinguishes it from non-minute sibling tools like index_option_cyb_qvix. However, it lacks an explicit verb such as 'get' or 'fetch', relying on the tool name and docstring structure to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative QVIX tools (e.g., index_option_50etf_min_qvix). The description simply labels the data without explaining the selection context or exclusions, offering no decision support beyond the resource name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the source URL and return type (pandas.DataFrame), but does not disclose additional behavioral details such as update frequency, time zone, or potential rate limits. With annotations covering the core safety aspects, 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is good for conciseness, but it redundantly repeats the same phrase '科创板 期权波动率指数 QVIX-分时' in both the first line and the :return: line. The URL is somewhat useful but the redundancy could be trimmed to a single sentence without loss of meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool with annotations and no output schema, the description is minimally viable. It states the data source and returns a DataFrame, but lacks details on expected columns, data granularity (e.g., 1-minute vs. 5-minute), or historical depth. This leaves some ambiguity for an agent seeking to use the data correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so the baseline for parameter semantics is 4. The description correctly implies no input is needed, and no parameter documentation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing the STAR Market (科创板) options volatility index QVIX intraday (分时) data, and the :return: line explicitly states what is returned. The '分时' term differentiates it from the non-min QVIX sibling tools, although it lacks a direct verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that for daily QVIX data one should use index_option_kcb_qvix, nor does it explain any distinguishing use cases among the many sibling option QVIX tools. The only context is a URL, which does not help with tool selection.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds the return type (pandas.DataFrame) and a source URL, but provides no additional behavioral context like update frequency, data history depth, or network dependency. It does not contradict the annotations, but adds only minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant, repeating '科创板 期权波动率指数 QVIX' twice and including a raw URL. It is structured like a docstring label rather than a concise explanation, yet it does front-load the core name and remains compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool, the description conveys the basic purpose and return type, but omits useful details such as whether the data is historical, the column structure, or the frequency of the QVIX values. Since there is no output schema, more context would improve completeness, but the current description is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the input schema is empty, so parameter documentation is not needed. Per the baseline for a zero-parameter tool, the description is not required to explain parameter semantics, and the schema coverage is effectively 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as the '科创板 期权波动率指数 QVIX' (STAR Market Option Volatility Index) and includes a :return: clause indicating a pandas.DataFrame. This clearly names the specific index and resource, and the KCB/STAR Market designation distinguishes it from sibling QVIX tools. However, it is more a title than an explicit action statement, so it lacks the full clarity of a verb-driven 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as index_option_300etf_qvix or other QVIX variants. It only states what it returns, without any selection criteria, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns a pandas DataFrame and provides a source URL, which gives some context. However, it does not disclose any additional behaviors such as rate limits, pagination, or error handling, which the annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections for URL, params, and returns, but it contains redundancy: '最新股票指数的成份股目录' appears both in the first line and the return description. The included URL is not essential for the AI agent and adds noise. It is moderately concise but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the return type (pandas DataFrame) and parameter guidance. However, it lacks details about the DataFrame columns or any potential edge cases, which would be helpful given the absence of an output schema. It 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'symbol' parameter and coverage is 0%. The description compensates by explaining that symbol is the index code and suggesting how to obtain it via ak.index_stock_info(). This adds meaningful guidance beyond the schema, which only shows a default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest constituent stocks of a stock index (最新股票指数的成份股目录). It uses an implicit 'get' verb and specifies the resource (index constituents). However, it does not differentiate from sibling tools like index_stock_cons_sina or index_stock_cons_csindex, missing the chance to distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 explains how to obtain the symbol parameter via ak.index_stock_info(), which is parameter-oriented rather than usage context. No when-to-use or alternative recommendations are given.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the limitation that only a limited number of indices are available, which is useful behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a URL and standard parameter/return documentation. Every part contributes useful information, with no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description covers the basic return type (pandas.DataFrame) and parameter, and annotations cover safety. However, it omits what the returned DataFrame columns are, does not list or link to supported index codes, and does not clarify the symbol format beyond 'index code', leaving some ambiguity for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must compensate. It does provide the parameter meaning (指数代码/index code), type (str), and the default from schema, but lacks details about acceptable symbol formats or supported index codes, which is a notable gap for a tool with one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves constituent stocks of an index from Sina's new index page, with an example URL. It specifies the resource (Sina index constituents) and the action (获取/retrieve), but does not explicitly differentiate from sibling index constituent tools like index_stock_cons or index_stock_cons_csindex.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, only a caveat that the interface currently supports a small number of indices. It does not mention sibling tools or suggest when not to use it, leaving usage decisions largely to the agent.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose other behavioral traits like date format requirements, data granularity, or potential pagination. With annotations covering the safety aspects, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with a clear title, source URL, param/type/return annotations. It is compact and front-loaded with the primary purpose in the first line. The param lines are repetitive but add value by documenting each field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain the return data, but it only says '每日分时行情' (daily minute quotes) without describing columns, how periods map to data granularity, or how start/end dates affect the result. It also lacks details like data coverage, timezone, or any access limitations. This is insufficient for a data-returning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter: symbol is the index code, period lists valid choices {'1','5','15','30','60'}, and start_date/end_date are start/end dates. This is critical because the schema only shows defaults and types. However, the description does not specify the exact date-time format, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning daily minute-level quotes for indices from Eastmoney, as evidenced by '东方财富网-指数数据-每日分时行情'. This is specific about the resource (index data) and data type, and the URL provides source context. However, it lacks an explicit verb like 'fetch' or 'get', making it slightly less direct than an action-oriented 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/5Does 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 are many sibling index tools (e.g., index_zh_a_hist for daily data), but the description does not mention when this minute-level tool is appropriate or what the data represents (e.g., intraday time-sharing).
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 already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds that the return type is a pandas.DataFrame and provides a source URL, but does not reveal any edge cases, rate limits, or data quirks. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal, with three components: title, URL, and return type. It is not verbose, but the structure is more of a stub than a well-organized explanation, lacking any usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, read-only, no output schema), the description is barely adequate. It mentions the metric and return type but omits details about the DataFrame columns, date range, or units, which would be valuable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. The description correctly does not need to explain parameters, and the return type is mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (Eastmoney), country (Canada), and metric (retail sales monthly rate), which distinguishes it from sibling macro tools. However, it lacks an explicit verb like 'fetches' or 'returns', relying on the title to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_canada_cpi or macro_australia_retail_rate_monthly. It simply states the topic and returns a DataFrame, leaving the agent to infer suitability.
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 already declare this as read-only, idempotent, and non-destructive, so the safety profile is clear. The description adds the data range and source URLs, which provide context about the data's provenance and scope, but does not disclose details like update frequency or network/dependency behaviors beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes redundant elements: the first line duplicates the title from annotations, and the two URLs add length without providing actionable instructions for the agent. It is front-loaded with the report name, but the extra lines could be streamlined for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, rich annotations, and no output schema, the description provides the essential facts (what data, range, and return type). However, it omits details about columns or content of the DataFrame, which would be helpful since there is no output schema to fall back on. This is a minor gap for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers this dimension. The description's mention of a fixed data range ('数据区间从 20120405-至今') reinforces that no user input is needed, and the return type is stated, providing adequate context for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '中国财新服务业PMI报告' (China Caixin Services PMI Report) and provides the data range starting from 20120405, making the tool's purpose clear. It is specific about the sector (services) and the data source, distinguishing it from official PMI tools, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_china_cx_pmi_yearly or macro_china_pmi_yearly. There are no conditional statements, exclusions, or mentions of alternative tools, leaving the agent to infer usage from the name alone.
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 already establish this as read-only, idempotent, and non-destructive. The description adds minimal behavioral context beyond a source URL and return type; it does not disclose data granularity, time range, or other traits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no redundant language. It includes the title, source URL, and return type in a compact format, but it is perhaps too sparse to be considered well-rounded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no output schema. It does not describe the columns of the DataFrame, the frequency of data, or the time period covered. The agent only knows the return type and the general topic, which is insufficient for fully understanding the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline of 4 applies, and the description does not need to compensate for parameter ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (central bank gold and foreign exchange reserves) and states the return type, making it clear the tool returns this data. However, it lacks a specific verb like 'get' or 'fetch', and it doesn't explicitly differentiate from sibling macro tools beyond naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no mention of context, and no exclusions or alternatives listed. The description only provides a data source URL and return type, offering no decision support.
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 already cover read-only, idempotent, and non-destructive behavior. The description adds a date range (20140115-至今) and a pandas.DataFrame return type, which are useful, but it does not disclose data frequency, column meanings, or update/refresh behavior, leaving partial ambiguity (e.g., '年度' vs. the full date range).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but repetitive: '中国年度外汇储备数据' appears twice, and the return annotations duplicate the earlier phrase. The URL and return type occupy space, but the structure is a bit loose and not front-loaded; it could be tightened to a single clear sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data tool, the description gives the essential data name, date range, source URL, and return type. However, it omits frequency details (despite the '年度' label), column layout, and how it differs from similar FX reserve tools, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description correctly indicates no inputs are needed and adds value by clarifying the returned data object, so it meets the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns China's annual foreign exchange reserves data, including a source URL and return type. It identifies the resource and conveys a data-retrieval purpose, though it does not explicitly differentiate it from sibling tools like macro_china_fx_gold or macro_china_foreign_exchange_gold at the same level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related alternatives, nor are any usage conditions or exclusions mentioned. The tool name and data type imply its use, but there is no explicit context for selection among the many macro_china_* siblings.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered. The description adds the data source URL and return type (pandas.DataFrame), but does not explain data frequency, granularity, or any other behavioral nuances. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing a title, source URL, and return type in a docstring-like structure. Every line serves a purpose (identifies resource, gives provenance, and output type), but it is under-specified rather than optimally concise. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is incomplete. It does not describe what the data actually means (e.g., monthly new loans, sector breakdown), the data frequency, or how it differs from similar macro indicators. The return description '新增信贷数据' just repeats the title, adding little value. Given the absence of an output schema, the description should provide more context about the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially complete (100%). The description does not need to explain parameters since there are none. Baseline of 4 for zero parameters is appropriate; no additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing China's new credit data (中国-新增信贷数据) and includes the data source URL. The resource is specific and the return type is stated, but it lacks an explicit verb and does not differentiate from other macro_china_* credit-related tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling macro_china_* tools, the description does not mention exclusions, prerequisites, or comparison to similar tools like macro_china_money_supply or macro_rmb_loan.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds useful context about data range, data source URLs, and that it returns a pandas DataFrame with current values in percent. However, it doesn't disclose whether the data updates frequently, whether all tenors are included, or any potential quirks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but somewhat unstructured, mixing a title, URLs, and docstring-style lines. The URLs add provenance but take up space without explaining behavior. The front-loading of the report name and data range helps, but the formatting is inconsistent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with strong annotations, the description provides the essential facts: the data source, time range, return type, and unit. However, it does not specify what columns the DataFrame contains (e.g., tenors like O/N, 1W, 1M) or whether this is a historical series or just current values, which is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty. The description correctly highlights the return type (pandas.DataFrame) and the unit (%), which is the key semantic info. No parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the Shanghai interbank offered rate (SHIBOR) report, with a data range and return type. It distinguishes itself from sibling macro tools by naming a specific financial report, though it lacks an explicit action verb like 'fetches' or 'returns historical 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/5Does 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 doesn't mention exclusions, alternatives, or the specific scenario for which SHIBOR data would be needed. The intended use is implicit from the name but not explicitly stated.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a source URL and return format (pandas.DataFrame), but no additional behavioral details such as data freshness, pagination, or rate limits. This meets the lower bar set by annotations but does not enrich much beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it repeats the same phrase '东方财富-外汇贷款数据' twice, which is redundant. It also mixes a URL and a Python-style docstring return tag, which is a bit unstructured. It earns a middle score because it is brief but not perfectly streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple no-parameter data fetch, the description gives the source and return type, which is enough to call it. However, it does not explain what the data contains (e.g., historical series, current values, units) or whether it is updated periodically, leaving gaps for an agent trying to interpret the result. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 information because none is needed. The return type is stated, which helps understand what the tool produces.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning East Money (东方财富) foreign exchange loan data, with a source URL. It distinguishes itself from sibling tools by naming the specific dataset, but lacks an explicit verb like 'get' or 'retrieve' and does not describe the data's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only provides a title and return type, with no context on typical use cases or comparisons to other macro_china 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds the source URL and return type, which is some useful context, but it does not disclose any other behavior such as data update frequency, potential errors, or limitations. Given annotations, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three short lines covering the data name, source URL, and return type. There is no wasted text, and it is front-loaded with the key identifier. It could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description provides only a high-level label. It does not explain what columns, frequency, or time range the data covers. An agent selecting this tool would lack a clear picture of what data it will get, making the description 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.
Parameters4/5Does 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 mentions the return type (pandas.DataFrame), which adds a bit of insight into what the agent will receive, though no parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing China macro leverage ratio data from the National Institute of Finance and Development Laboratory. It names the specific resource and the data type returned, which distinguishes it from sibling macro tools. However, it lacks an explicit verb like 'retrieve' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites. The context is implied only by the title and description, which is insufficient for an agent to choose it over other macro data 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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), which is useful, but it does not disclose data granularity, update frequency, or other behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first line is identical to the title, making it redundant. The URL and return type are useful, but the structure is a set of fragments rather than a coherent, front-loaded description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a data-fetching tool with no output schema. It specifies the source and return type, but does not mention the columns of the DataFrame or any details about the data content, which is a gap for a macro economic indicator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has 0 parameters, and the schema description coverage is 100%. The baseline for 0 parameters is 4, and the description does not need to add parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource as Germany's seasonally adjusted trade balance from East Money, which is a clear and distinct resource among siblings like macro_uk_trade or macro_germany_cpi. However, it lacks an explicit verb like 'retrieves' or 'gets', relying on the URL and return type to imply data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or exclusion criteria, leaving the agent without contextual selection information.
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 already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds the return type (pandas.DataFrame) and a source URL, but does not disclose additional behavioral details like data granularity or update frequency. This is adequate given the strong annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite short, essentially a title, a URL, and a return-type note. It is not verbose, but it lacks a structured explanation of the data and could benefit from a brief sentence describing what 'leading indicator final value' means. It is under-specified rather than concise in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimal but mostly sufficient for an agent to know what data it returns. However, it does not explain the data's frequency or scope (e.g., monthly releases, historical coverage), which would be helpful for context. The strong annotations reduce the burden, but the description could still be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so the baseline for parameter semantics is 4. The description correctly notes the return type and data source, but there is nothing to add for parameter explanations. The score reflects that the tool is parameterless and no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning Japan's leading indicator final value from Eastmoney's economic data, which clearly distinguishes it from sibling macro tools (e.g., macro_japan_bank_rate, macro_japan_cpi_yearly). It lacks an explicit verb like 'get' or 'fetch', but the noun-phrase description is unambiguous about the data resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no exclusions. While the no-parameter design implies simple use, there is no explicit or implicit context helping an agent decide between this and similar Japan-specific macro indicators.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds the data range and source URL, plus a return type of pandas.DataFrame. No contradictions. However, it doesn't disclose any potential behavioral traits such as update frequency, data limitations, or authentication requirements, which would add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundant repetition: '美国商品期货交易委员会CFTC外汇类商业持仓报告' appears both at the start and again in the :return: line. The URL and :rtype: lines are useful, but the duplication wastes space and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description provides the essential facts: the report type, data range, source URL, and return type. However, it does not describe the columns or content of the DataFrame, update frequency, or any special usage constraints, so it falls short of fully equipping an agent to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. With no parameters to describe, the description does not need to compensate. The baseline of 4 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '美国商品期货交易委员会CFTC外汇类商业持仓报告' (CFTC FX commercial holdings report), which is specific and distinguishes it from sibling tools like the goods holding variant. It also states the data range (19860115-至今). However, it lacks an explicit action verb like 'retrieve' or 'return', though the :return: line clarifies the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many similar CFTC holding tools (e.g., macro_usa_cftc_c_holding, macro_usa_cftc_merchant_goods_holding, macro_usa_cftc_nc_holding). It does not mention exclusions or alternatives, leaving the agent to infer usage solely from the name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a source URL, the date range, and the return type (pandas.DataFrame), but it does not go deeper into behavior like data granularity, adjustment, or potential HTTP failures. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat repetitive: the title, the first sentence, and the :return: line all state the same report name. The URL and :rtype: line are useful, but the redundancy makes it less crisp than it could be. It is not a long description, so it earns a near-average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should describe return values. It states the return type is a pandas.DataFrame, but it does not mention columns, units, or the meaning of the data fields. The source URL provides a reference, but an agent would still be unclear about what exactly is in the returned DataFrame. The data range is given, which is helpful, but column details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100% (empty schema). With zero parameters, the baseline is 4. The description does not need to clarify parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching the US FHFA House Price Index monthly rate report, a specific economic indicator distinct from the many other macro_usa_* siblings. It provides the data range and a source URL, which adds specificity beyond the tool name. However, it does not use an explicit verb like 'fetch' or 'retrieve', relying on the noun '报告' to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as macro_usa_spcs20 or other house-price-related tools. It merely states what the report contains and its data range. There is no mention of exclusions, prerequisites, or preferred contexts.
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 already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the data range and specifies the return type as pandas.DataFrame, providing some behavioral context. However, it does not describe data frequency or content details, so it 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but repeats the report name three times and includes a URL that may not be necessary for an agent. It could be more streamlined, though it is still relatively short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, so the description's mention of return type and date range helps. However, it lacks explanation of what the NAHB index measures or how the returned data is structured, which is a gap for an agent encountering this tool among many similar macro indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameters. The baseline of 4 applies because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is the US NAHB housing market index report with a specific date range (from 19850201 to present), giving a clear resource and scope. However, it does not explicitly differentiate from sibling tools like macro_usa_house_price_index or macro_usa_exist_home_sales, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 compared to alternatives. It only describes what the tool provides, without any context on use cases or exclusions, earning a low score for usage guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful context: data range, source URL, and return type (pandas.DataFrame). It does not contradict annotations, but it adds little beyond those basics—no mention of update frequency, columns, or units. This is acceptable for a zero-param read-only tool, though richer behavioral detail would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (three lines), but the title string '美国Markit服务业PMI初值报告' is repeated verbatim in the :return: field, which is redundant waste. The URL and :rtype: are useful additions. It is appropriately short but could be tightened by removing the duplication and structuring the info more deliberately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only macro data tool, the description covers the essential what, source, and date range. However, there is no output schema, so the description carries the burden of explaining return values; it only states the return type (pandas.DataFrame) and repeats the report name without detailing columns, index, or value units. This is minimally viable but leaves the agent guessing about the actual data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so per the rubric the baseline is 4. The input schema is an empty object with 100% coverage, and the description introduces no parameter information since there are none to document. Nothing more is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource precisely: US Markit Services PMI preliminary (flash) report, with a clear date range (20120701-present) and source URL. It distinguishes from similar siblings like macro_usa_pmi (ISM manufacturing) and macro_usa_ism_non_pmi (ISM services) by specifying 'Markit' and '服务业' (services). However, it lacks an explicit action verb like '获取' (fetch/retrieve), relying on the :return: docstring to imply data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_usa_pmi, macro_usa_ism_non_pmi, or macro_euro_services_pmi. The date range is a factual constraint, not usage guidance, and no exclusions or alternative recommendations are given. With several closely related macro PMI siblings, this absence of differentiation guidance is a real gap.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds the return type (pandas.DataFrame), which is useful but not a behavioral trait. It does not disclose any additional traits such as data freshness, pagination, or unique constraints. With annotations covering safety, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured: a title line, a source URL, and a docstring with param/return/type. Each element is relevant, though the URL and docstring could be seen as slightly redundant. Overall, it is appropriately sized with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains, but it only says '单月票房' (monthly box office) without specifying columns, scope, or data source details. It also lacks guidance on when to choose this tool over sibling movie box office tools. This is insufficient for a tool with no structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies the 'date' parameter as a string with a default, but the description's docstring explains that the date determines the month for which box office data is returned. This adds meaningful semantics. However, the format (e.g., YYYYMMDD) is only implied by the default value '20240218', not explicitly stated, so it is not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as monthly movie box office data and explains the date parameter's role in selecting the month. While it lacks an explicit verb like 'get' or 'list', the docstring's return statement makes the function's purpose apparent. It does not explicitly distinguish from sibling movie box office tools, but the 'monthly' qualifier is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling tools (e.g., movie_boxoffice_daily, movie_boxoffice_weekly, movie_boxoffice_yearly). There are no conditions, exclusions, or alternative recommendations. The only hint is the name and the date parameter description, which is insufficient for an agent to select among closely related 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context by providing the source URL and clarifying that the date parameter selects the year containing that date. However, it does not disclose data freshness, potential delays, or edge-case behavior such as invalid dates or empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured as a docstring with param, type, return, and rtype sections. The URL is useful for provenance. The only minor redundancy is that the first line repeats the title/annotation, but overall the content is concise and free of unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description provides the source URL, parameter semantics, and return type. However, there is no output schema and no description of the DataFrame's columns, index, or typical row count. It also lacks context about how this tool relates to the numerous movie box office siblings, which could leave an agent uncertain about which to select.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'date' is described as '当前日期所在年度的票房数据' (box office data for the year containing the current date), which adds meaning beyond the raw schema by linking the date to a yearly aggregation. The default value '20240218' hints at the YYYYMMDD format, but the description does not explicitly state the expected format, range, or whether the date must be a trading day.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '电影票房-年度票房' (movie box office - annual) and states that it returns '年度票房' (annual box office) as a DataFrame. This clearly indicates the annual scope and, through the name, helps distinguish it from sibling tools like movie_boxoffice_daily and movie_boxoffice_monthly. However, it lacks an explicit verb like 'fetch' or 'query' and largely repeats 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/5Does 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 that it is appropriate for annual box office data while daily, weekly, monthly, or real-time siblings exist for other time granularities. No exclusions, prerequisites, or alternative recommendations are given.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the need for a 'cookie' parameter (implying authentication) and a specific source URL, but it does not explain the cookie's purpose or any rate limits, pagination, or error behavior. This partial disclosure is below the bar for 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and organized with URL, :param, and :return sections. It front-loads the resource name and URL, which is efficient. However, it redundantly repeats the title as the first line, which adds no new information. Overall, it is concise and structured well enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema) and helpful annotations, the description is minimally adequate. It covers the essential inputs (date, cookie) and return type (DataFrame), but lacks usage context, output details, and caveats about cookie authentication. It does not explain what data the DataFrame contains beyond '分红派息', leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does document the date parameter with a format ('YYYYMMDD'), which is essential. However, the cookie parameter is documented only as 'cookie', adding no meaning beyond the schema's property name. The date format is useful, but the missing explanation for cookie and lack of example values prevent a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('百度股市通-交易提醒-分红派息') and implies a retrieval action via ':return: 交易提醒-分红派息DataFrame'. It is distinguishable from the sibling 'news_trade_notify_suspend_baidu' by explicitly mentioning '分红派息' (dividend/interest). However, it lacks an explicit verb like 'fetch' or 'list', relying on the noun phrase and return type to convey 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/5Does 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 scenarios, exclusions, or related tools. The only context is the URL and parameter descriptions, which do not help an agent decide between this and the many sibling tools (e.g., news_trade_notify_suspend_baidu).
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and the pandas.DataFrame return type, but does not disclose additional behaviors such as data delay, rate limits, or handling of invalid symbols. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a purpose statement, URL, and docstring. It is front-loaded and easy to scan, though the purpose is restated in the rtype, adding minor redundancy. Overall, it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with annotations and no output schema, the description covers the core function, parameter, and return type. However, it lacks usage context, differentiation from similar option-minute tools, and details about the data's time range or interval. It is sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a docstring explaining that 'symbol' is the option code (期权代码), which adds meaning beyond the schema's bare property name. However, it does not elaborate on format, allowed values, or how to obtain a valid symbol. The default value provides an example but no further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '指定期权的分钟频率数据' (minute-frequency data for specified options), which clearly identifies the tool's function. The URL to Sina Finance's option quotes page indicates the data source. However, it does not explicitly differentiate from similar sibling tools like option_sse_minute_sina, so it is clear but not distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no exclusions, and no mention of data frequency or time range. It only states the parameter and return type, leaving the agent to infer usage context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type but does not disclose behavioral traits such as data coverage, potential missing dates, or any quirks of the web source. This is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured as a docstring with clear parameter descriptions and return type. However, it includes the redundant URL line and the title is repeated, which adds unnecessary clutter. The long symbol list is necessary but makes the description somewhat unwieldy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should ideally detail the returned data columns or structure, but it only says '日频行情数据' (daily market data) and pandas.DataFrame. This is sufficient for a basic understanding but leaves ambiguity about what fields are present. For a simple data retrieval tool with two parameters, 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema by listing the full set of valid symbol choices and defining trade_date as 交易日. Although the exact date format is not explicitly stated, the default value '20191017' implicitly indicates YYYYMMDD, and the description compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving daily-frequency market data for options on the Zhengzhou Commodity Exchange, with a specific URL and return type. However, it lacks an explicit verb like 'get' or 'fetch' and does not distinguish itself from similar sibling tools such as option_hist_yearly_czce or option_hist_dce.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only lists parameters and return type, but does not mention contexts, prerequisites, or differences from other option data tools like option_hist_shfe or option_hist_dce.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description need not repeat safety. It adds the data start date (20150209) and source URL, providing some context beyond annotations, but does not disclose behavior on invalid dates, data scope, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear title, source URL, and structured docstring entries for parameter and return. Each line serves a purpose, though it reads more like raw documentation than a crafted tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool returning a DataFrame, the description provides basic structure (date input, DataFrame return) but lacks details about the specific risk indicators included or the output columns. Given the abundance of similar option tools, more specificity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'date' parameter. The description explains that 'date' is a date and that data begins at 20150209, which adds meaning beyond the schema, but it does not specify the exact format or accepted range, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as SSE stock option risk indicators, with a source URL and return type. It distinguishes this tool from siblings like option_sse_greeks_sina or option_risk_analysis_em by specifying the official SSE endpoint, though it lacks an explicit verb such as 'fetch' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives. It does not state conditions, exclusions, or relationships to sibling tools, leaving the agent to infer usage from the name alone.
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 already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the data is 'real-time' and that it returns a pandas DataFrame, which is slightly beyond annotations. However, it mostly duplicates the title and does not disclose more about data source behavior or limitations, yet it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and follows a docstring structure with param and return sections. It is front-loaded with the purpose, but the first sentence exactly repeats the title annotation, so it does not add new information at the start. Still, it is free of fluff and well-organized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks detail about the DataFrame contents (columns, meaning of the data), the interpretation of the symbol values (e.g., that they are ETF codes), and does not clarify the distinction from similar option tools. Since there is no output schema, the description should carry more explanatory burden, but it only gives vague 'information about the underlying asset'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with a default but no description. The description explicitly lists two valid values (sh510050, sh510300), which adds meaning not present in the schema. This is helpful for an agent to know the expected format, though it does not explain what each symbol represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Real-time data of options underlying asset' identifies the specific resource (underlying spot data) and implicitly distinguishes from sibling tools like option_sse_spot_price_sina via the word 'underlying'. However, it lacks an explicit verb like 'get' or 'retrieve', and the noun-phrase style makes it more of a title than a clear action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides parameter examples (sh510050, sh510300) but does not explain when this tool is appropriate compared to the many sibling option tools, nor does it mention exclusions or prerequisites.
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?
Annotations already cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the description adds value by disclosing that data is real-time updated and cannot be queried for history. The sample DataFrame also reveals the return format, including possible NaN values (e.g., Iran's QoQ), which is useful behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The initial lines are concise and front-loaded with the key facts (real-time, no historical), but the description is dominated by a large 50-row sample table. This is excessive for a tool description; a simple list of column names would suffice. The structure is front-loaded but overall not concise due to the data dump.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 rich annotations, the description covers the core behavior: real-time data, no historical support, and a DataFrame of economic indicators across countries. However, it omits details like GDP units, the purpose of the URL parameter, and the data source name. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional `url` parameter with a default value and zero description coverage (context signals confirm 0%). The description only includes ':param url:' without any explanation of what the URL is for or when to override it. With schema coverage at 0%, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as '奇货可查-工具-各地区经济数据' (QHKC Tool - Regional Economic Data) and includes a sample DataFrame with country names and economic indicators, making it evident that the tool retrieves current economic data across countries/regions. The verb is implicit rather than explicit, but the title and sample output remove ambiguity. It is distinguishable from siblings like macro_china_gdp by its cross-country regional focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states '实时更新数据, 暂不能查询历史数据', which effectively tells the agent this tool is for current real-time data and not for historical queries, serving as a when-not-to-use note. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of alternative tools. Usage context is implied by the sample data and the 'real-time' note.
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 already declare the tool as read-only, idempotent, and non-destructive, so the description need not repeat these. It adds the 'real-time' nature and source URLs, but does not disclose other behavioral aspects such as data freshness caveats, rate limits, or error conditions. The description is not contradictory to annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a raw documentation string with URLs and a parameter doc. While it is not overly verbose, the placement of URLs before the parameter documentation creates a slightly awkward flow. It is acceptable but not well-structured for quick consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description covers the essential aspects: valid symbols, return type, and data source. However, since there is no output schema, it does not describe the specific columns or fields returned, which would be useful for an agent to interpret the DataFrame. It is minimally complete but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has no parameter descriptions (0% coverage), the description provides a comprehensive list of valid symbol values and points to a sibling function for the full symbol table. This effectively compensates for the schema's lack of documentation, giving the agent enough information to select a valid parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Shanghai Gold Exchange real-time market data, and the name 'spot_quotations_sge' distinguishes it from siblings like historical or benchmark tools. However, it is expressed as a noun phrase rather than an explicit verb-based action, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It only mentions that one can get the symbol table via another function, which is more about parameter selection than tool selection. There are no explicit exclusions or alternative tool 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the data source URL and return type (pandas.DataFrame), which provides some context beyond the annotations. However, it does not disclose any potential quirks, output details, or limitations, so it's 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured as a docstring, with a title, source URL, parameter, and return sections. It avoids unnecessary verbosity. The only minor redundancy is that the title line duplicates the annotation title, but this is not a significant waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description is adequate: it explains what data it returns, the parameter meaning, and the return type. However, it does not describe the returned DataFrame's columns, how the output is structured, or any caveats about data availability. Given the simple nature, this is minimally sufficient but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with 0% schema description coverage, so the description must compensate. It documents ':param symbol: 股票代码' (stock code) and ':type symbol: str', which adds essential meaning. The URL also contains an example stock code (600004), providing an implicit format hint. Yet it lacks explicit details on code format, prefix conventions, or examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose via the title '新浪财经-发行与分配-增发' (Sina Finance - Issuance and Distribution - Additional Issuance) and the return doc '返回增发详情' (return additional issuance details), clearly indicating it retrieves additional stock issuance data for a given symbol. However, it does not distinguish itself from the many sibling stock-related tools beyond its specific sub-type, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions, prerequisites, or related tools. Only parameters and return type are given, with no contextual usage advice.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and the source URL, which are useful but do not disclose deeper behaviors like data frequency, freshness, or exact columns. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring format with title, URL, param, and return sections. Each line serves a purpose, and there is no superfluous text. It is appropriately sized, though the URL might be redundant for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a basic return description (a DataFrame of high/low counts) but lacks details on columns, time period, or data granularity. Given the tool's simplicity (one parameter), this is adequate but leaves room for interpretation about the exact output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description or enum for the 'symbol' parameter (0% coverage), so the description compensates by listing allowed values: 'all', 'sz50', 'hs300', 'zz500'. However, it does not explain what each value represents (e.g., which index or market scope), so the agent knows valid inputs but not their semantic differences.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose via its title '乐咕乐股-创新高、新低的股票数量' (number of stocks hitting new highs and lows) and the return type mentions '创新高、新低的股票数量'. It is specific about the resource, but lacks an explicit verb like 'get' or 'fetch', and does not distinguish from sibling tools such as stock_rank_cxg_ths which also deals with new highs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only includes parameter choices and a source URL, but does not specify scenarios, exclusions, or mention any related tools. This is minimal and leaves the agent without selection criteria.
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 (readOnlyHint, idempotentHint, destructiveHint) already declare a safe read operation. The description adds only the return type (DataFrame) and data content, but no additional behavioral context such as data frequency, coverage, or potential side effects. With annotations present, this is an average contribution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but redundant, essentially repeating the title twice and adding only the return type. It is under-specified rather than concise, with no additional value beyond the structured title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter data retrieval tool with no output schema, the description adequately names the two data fields and return type. However, it lacks context on data frequency, universe definition, and source, making it slightly less complete than ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers all inputs. The description has nothing to add about parameter behavior, and the baseline for zero-parameter tools is 4. It correctly communicates no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides equal-weighted and median PE ratios for all A-shares. The verb is implied ('get'/'fetch') and the resource specificity is good, but it doesn't distinguish itself from sibling tools like stock_index_pe_lg or stock_market_pe_lg.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions or preferred contexts, leaving the agent without criteria for selection among the many PE-related sibling 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context: data source (East Money), market scope (沪深京), and pandas DataFrame return type. However, it creates ambiguity about whether 'symbol' accepts a code (BK0818, per the URL) or a name ('可燃冰', per the default), which is a behavioral gap not resolved by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the source and purpose, followed by a tight param/return docstring. Every line contributes (source, parameter, return type). It reads as a raw docstring rather than a crafted prose description, but there is zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter, read-only tool with annotations, the description covers source, market scope, param type, and return type. But with no output schema, it should at least hint at key return columns or data shape; it only says '概念板块-实时行情'. It also omits how to discover valid concept board codes, which is a notable completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It adds meaning by defining symbol as 概念板块代码 (concept board code), type str, and provides a URL example (BK0818). However, the default value is a Chinese name rather than a code, and no valid values or lookup method are given, leaving the parameter semantics partially ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: it retrieves real-time quotes (实时行情) for concept boards (概念板块) from East Money's market center covering Shanghai/Shenzhen/Beijing boards. The 'spot' vs 'hist'/'cons' suffix pattern among sibling tools implicitly distinguishes it, though it never explicitly names alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the many related siblings (e.g., stock_board_concept_hist_em for history, stock_board_concept_name_em for board lists). Usage is only implied through the param/return docstring; there are no exclusions, prerequisites, 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the description's lack of safety warnings is acceptable. It adds the data source URL and return type (DataFrame), but no further behavioral context such as pagination, rate limits, or data coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, source URL, parameter, and return type. It is well-structured and front-loaded, though the URL and title are slightly repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with strong annotations, the description covers the essential return type and parameter semantics. It is incomplete regarding the structure of the returned DataFrame and doesn't give an example symbol, but it meets a minimum viability for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description coverage, so the description's ':param symbol: 板块名称或者板块代码' is essential. It tells the agent that the symbol can be a name or code, which adds meaning beyond the schema. However, it lacks examples or a note about the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as industry sector constituents from Eastmoney (沪深板块-行业板块-板块成份), and the return type clarifies it provides constituent data. It is specific about the domain and distinguishes from sibling tools like stock_board_industry_spot_em, though it lacks an explicit verb such as 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 constituents as opposed to sector summaries or historical data, nor does it list any 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 already declare read-only, idempotent, and non-destructive behavior, so the description only needs to add complementary context. It adds the return type (pandas DataFrame) and the parameter format (stock code with market identifier). It does not elaborate on data scope, potential errors, or update frequency, but for a read-only fetch tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with a URL, parameter explanation, and return type. It follows a clear structure with no wasted words, though the URL is somewhat long but serves as a reference. Each line contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter, read-only tool with strong annotations, the description provides the essential information: purpose, parameter, and return type. It does not enumerate DataFrame columns or data range, but the name and context from the financial statement type make this acceptable. No output schema exists, so the return type mention is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'symbol' parameter (0% coverage), so the description must clarify it. It states '股票代码; 带市场标识' (stock code with market identifier) and the URL example shows 'sh600519'. This gives basic meaning, but does not specify exact format rules (case, market prefixes) or constraints, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the cash flow statement by reporting period for a stock from East Money. It includes a source URL and specifies the return type. However, it does not explicitly differentiate from sibling tools like quarterly or yearly cash flow statements, though the name and title already imply the 'by report' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_cash_flow_sheet_by_quarterly_em or stock_cash_flow_sheet_by_yearly_em. It lacks any mention of prerequisites, intended use cases, or exclusions, leaving the agent without context for selection among similar financial statement 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that it returns a pandas DataFrame from a specific East Money URL, which implies a web data fetch, but it does not disclose potential rate limits, authentication needs, or data update frequency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a docstring format with source URL, parameter, and return sections. It is front-loaded with the title and contains no unnecessary fluff, though the return line repeats the title wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description gives the source, parameter, and return type, which is adequate. However, without an output schema, it does not describe the DataFrame's columns or the nature of '市场参与意愿' beyond the label, leaving an agent uncertain about the exact data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string 'symbol' with a default and no description. The description compensates by explaining that symbol is a stock code (股票代码) and provides an example URL with '600000'. However, it does not specify the expected format (e.g., six-digit with leading zeros) or acceptable exchanges, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching East Money's 'market heat - market participation willingness' data for a given stock symbol, with a source URL and return type. It distinguishes itself from sibling stock_comment_detail tools by specifying the data category (desire/participation willingness), 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 Guidelines2/5Does 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 the many sibling stock_comment_detail tools (e.g., stock_comment_detail_scrd_focus_em). It does not state prerequisites, symbol format requirements, or whether it should be preferred over other market-heat 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the return type (DataFrame) and a source URL, which gives some context, but does not disclose pagination, rate limits, or other behavioral aspects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with 5 lines, front-loading the source and URL. It is efficient and free of fluff, though the first line duplicates the title from annotations, which is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains that it returns a DataFrame with the market heat/user interest index. For a single-parameter retrieval tool with clear annotations, this is largely sufficient, though it could specify the DataFrame's columns or whether historical data is included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description bears the burden. It defines `symbol` as '股票代码' (stock code) with type str and includes a URL example (600000), providing basic semantic meaning. However, it does not specify the expected format, market prefix, or constraints, leaving some ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific data source ('东方财富网-数据中心-特色数据-千股千评-市场热度-用户关注指数') and return type (pandas.DataFrame), making the tool's function clear. However, it lacks an explicit verb like 'get' or 'fetch', and the first line is essentially a breadcrumb phrase. It distinguishes from siblings by naming the exact metric (user attention index).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related tools such as stock_comment_detail_scrd_desire_em or stock_comment_em. The description only states parameters and return type, leaving the agent to infer usage context without any comparative direction.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a pandas.DataFrame and specifies the parameter as a concept name, but does not disclose additional behaviors like data range, frequency, or limitations. With annotations covering the safety aspect, this is acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a docstring-style block with title, URL, and param/return annotations. It is not front-loaded with a clear single sentence, and the URL is arguably unnecessary for an agent. However, it is not overly long and each line carries some information, so it earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain the return value. It states the return type is 'pandas.DataFrame' and describes it as '概念历史资金流' (concept historical capital flow), but does not detail the columns or the historical range. Given the tool's simplicity, this may be sufficient for an agent to infer the output, but it lacks explicit column information that would help with consuming the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'symbol' with zero description coverage. The description compensates by stating ':param symbol: 概念名称' (concept name), which is exactly what the parameter expects. It also provides a default value ('数据要素') in the schema, giving concrete context. For a single-parameter tool, the description adequately explains the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: '东方财富网-数据中心-资金流向-概念资金流-概念历史资金流' (Eastmoney concept historical capital flow), and the return type 'pandas.DataFrame' indicates it fetches data. The tool name also confirms the purpose. However, it lacks an explicit verb like 'get' or 'retrieve', and the title is more of a navigation path than a sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 conditions, exclusions, or recommend other tools (e.g., stock_sector_fund_flow_hist for industry sectors). Usage is only implied by the name and title.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose behaviors like date range inclusivity, pagination, or what specific columns are returned. It is consistent with annotations, adding marginal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with source, parameters, return type, and is free of unnecessary elaboration. It is compact and scannable, though it includes a URL that could be considered extra but is useful as a reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity data retrieval tool with no output schema, the description covers the basic purpose and parameters, but lacks date format details, return column information, and differentiation from closely related sibling tools. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists symbol with explicit choices {'A股', 'B股', '基金', '债券'} and identifies start_date/end_date as 开始/结束日期. However, it omits the date format (though schema defaults imply YYYYMMDD) and does not specify whether dates are inclusive or if there are constraints on range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves 大宗交易每日明细 (block trade daily details) from Eastmoney's data center, with a URL and return type. It distinguishes from sibling tools like stock_dzjy_mrtj (每日统计) by the explicit '每日明细' label, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the sibling stock_dzjy_* tools (e.g., mrtj, hygtj, sctj) or explain scenarios where daily details are appropriate over daily statistics. Usage is only implied by the name and description.
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 already declare readOnly, openWorld, idempotent, and non-destructive hints, so the bar is lower. The description adds that it returns a pandas DataFrame and provides source URLs, but does not disclose additional behavioral traits such as data freshness, error handling, or pagination. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with title, URLs, parameter docs, and return type. It is not overly long but contains redundancy (title repeated in return line) and non-essential URLs, making it somewhat cluttered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description is fairly complete for a 2-param read-only tool: it explains the parameters and return type. However, it does not detail the DataFrame structure or column names, which could be important for the agent to interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining 'symbol' as stock code and 'indicator' with explicit allowed choices ('按报告期', '按单季度', '按年度'). This adds meaningful semantics beyond the schema, though the symbol format is not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource as '同花顺-财务指标-利润表' (THS financial indicators - income statement) and includes source URLs, making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools like stock_financial_benefit_new_ths, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only documents parameters and return type, without mention of appropriate use cases, exclusions, or preferred scenarios.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it returns a pandas DataFrame and lists the valid values for symbol, but it does not disclose behaviors like stock code format expectations (e.g., 'sh' prefix) or data granularity. This is minimal additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with parameters and return type, which is reasonably organized. However, it includes a long, specific example URL that adds noise and may confuse the agent, and it repeats the title phrase multiple times. It is not as concise or front-loaded as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two optional parameters and no output schema. The description covers the purpose and parameters, but it omits crucial practical details like the stock code format (whether to include 'sh'/'sz' prefix) and how the returned DataFrame is structured. Given the abundance of sibling financial tools, some usage context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It provides meaningful semantics: 'stock' is identified as a stock code, and 'symbol' is explicitly enumerated with choices of 资产负债表, 利润表, 现金流量表. This is far more than the bare schema, though the stock format is left somewhat vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Sina Finance three major financial statements) and the parameters indicate it retrieves balance sheet, income statement, or cash flow statement for a stock. While not phrased as an explicit verb phrase like 'Get', the intent is clear and distinct from pure tautology. It doesn't explicitly differentiate from sibling tools like stock_financial_abstract, but the scope is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_financial_abstract, stock_balance_sheet_by_report_em, or other financial statement tools. There is no mention of suitability context, prerequisites, or exclusions. The description simply presents what it does without usage direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds the data source URL and parameter choices but does not disclose additional behavioral traits such as default behavior, pagination, or rate limits, missing the opportunity to enrich beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but includes a long URL with a tracking refCountId that adds noise. The structure follows a docstring pattern with title, URL, param, and return sections, which is generally clear but not as polished or front-loaded as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the parameter choices and return type but lacks an output schema or details about the DataFrame columns. For a simple one-param tool, it is mostly sufficient, but it does not specify what data fields are returned or whether it covers all A-shares, 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a string with a default, but the description enriches it by listing the exact allowed choices for symbol: {‘即时’, '3日排行', '5日排行', '10日排行', '20日排行'}. This is critical for correct invocation since the schema lacks an enum or descriptions, fully compensating for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '同花顺-数据中心-资金流向-个股资金流' (individual stock fund flow) and states the return type as a pandas DataFrame, making it clear the tool retrieves individual stock fund flow data. It differentiates from sibling tools like stock_fund_flow_concept and stock_fund_flow_industry by specifying '个股' (individual stocks). However, there is no explicit verb like 'get' or 'query', which slightly weakens purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling fund-flow tools (e.g., stock_sector_fund_flow_rank, stock_market_fund_flow). It only lists the symbol parameter choices, implying usage for ranking periods but no exclusions or alternatives, leaving the agent to infer the appropriate context.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is covered. The description adds the return type (pandas.DataFrame) and the source URL, which is useful behavioral context. However, it does not disclose details like column names, data freshness, or whether the symbol must be a 6-digit code, so it only partially adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a concise docstring with URL, param, and return sections. It is compact and easy to parse, though it repeats the title in both the first line and the return line, which is slightly redundant but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with good annotations and a clear return type, the description is fairly complete. It identifies the data source, the parameter meaning, and the return structure. It lacks detail on the DataFrame's columns or symbol format, but given the simplicity and existing annotations, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description provides ':param symbol: 股票代码' (stock code), which clarifies the meaning of the single parameter. The default value '600004' serves as an example. This sufficiently compensates for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '新浪财经-股本股东-基金持股' (Sina Finance - Shareholders - Fund Holdings) and includes a source URL, clearly indicating it retrieves fund holding data for a stock. Although no explicit verb like 'get' or 'fetch' is present, the title and context make the purpose unambiguous. It also differentiates from sibling tools like stock_main_stock_holder by specifying '基金持股' (fund holdings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. No mention of prerequisites, scenarios, or exclusions. The description is purely descriptive and does not help the agent decide between this and the many similar stock holder 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?
Annotations already declare this as a read-only, idempotent, non-destructive operation, so the description does not need to repeat that. It adds the return type (pandas DataFrame) and the meaning of the date parameter (报告期/reporting period), which provides some extra context. However, it does not disclose other behavioral details such as pagination, rate limits, or data granularity beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured as a docstring, with a title, URL, parameter description, and return type. Every line serves a purpose, and it is easy to scan. The inclusion of the URL may be redundant but does not detract significantly from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with robust annotations, the description covers the basic purpose and return type but falls short in differentiating from close sibling tools and explaining the date parameter's format or possible values. Without an output schema, it would benefit from describing the DataFrame columns beyond just '十大股东'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'date' parameter, but the description partially compensates with ':param date: 报告期' and ':type date: str', clarifying that date refers to a reporting period. It does not explicitly state the format (YYYYMMDD) or valid values, relying on the schema default example. Thus, it adds basic meaning but lacks depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: retrieving top-10 shareholder data from East Money's shareholder analysis section, as indicated by the title and '十大股东' return type. It distinguishes from sibling tools like stock_gdfx_free_holding_analyse_em by specifying '十大股东' (top 10 shareholders) rather than free-float holdings, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling tools for different holding analyses (e.g., free holding, holding change, holding detail), the lack of differentiation or explicit usage context is a significant gap. The URL merely points to the data source but does not explain selection criteria.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a pandas DataFrame of top 10 circulating shareholders, which is useful. However, it does not disclose data scope (e.g., all stocks vs. a single stock), pagination, or error behavior, so behavioral context remains thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and logically structured with title, URL, parameter, and return lines. The title line duplicates the annotation title, which is slightly redundant, but the URL and parameter documentation earn their place. It is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description is too sparse for a shareholder analysis tool. It fails to clarify whether the query is for a single stock or all stocks, what the resulting DataFrame columns represent, or how the date parameter affects the output. Given the complexity and many siblings, the description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides 'date' as a string with default '20210930'. The description adds that it is the '报告期' (report period), giving essential meaning. While it does not explicitly state the format (e.g., YYYYMMDD), the default strongly implies it. For a single-parameter tool, this is adequate compensation for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and content: East Money's shareholder holding change statistics for top 10 shareholders, with a specific URL. The title and name align on the main purpose, but there is no explicit verb like 'fetch' or 'query'. A minor inconsistency exists between the title (十大股东) and return (十大流通股东), yet it still distinguishes from siblings like stock_gdfx_holding_analyse_em by emphasizing 'change' statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling shareholder analysis tools. There are no alternatives, exclusions, or prerequisites. The only usage hints are the name and the parameter documentation, so an agent cannot judge when this tool is appropriate.
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 already declare the tool as read-only, idempotent, and non-destructive, so the description does not repeat these. It adds that the date parameter is a trading day and that the result is a pandas DataFrame, providing some behavioral context. However, it does not disclose details like data granularity, potential network behavior, or exact contents, so the added value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact, consisting of a title line, a URL, and a concise docstring for the parameter and return. It is front-loaded with the source name and presents information in a structured, scannable format with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the source, parameter, and return type, which is adequate for basic use. However, it does not explain what columns or event types are included in the returned 'company dynamics' DataFrame, nor does it explicitly state the date format. An agent would need additional inference to fully understand the output content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name, type, and default value, with no descriptions. The description compensates by stating ':param date: 交易日' (trading day) and using the default '20230808' to imply a YYYYMMDD format. This clarifies the meaning and format of the parameter, though it could be more explicit about allowed date ranges or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially repeats the title '东方财富网-数据中心-股市日历-公司动态' and adds a URL and docstring. It clearly implies the domain (company dynamics in the stock calendar) but lacks an explicit action verb like 'retrieves' or 'queries'. The return type as a pandas DataFrame and the date parameter strongly hint at data retrieval, making it somewhat clear, but the purpose is not stated as a directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternative tools for similar data. The description does not mention prerequisites, exclusions, or alternative tools. It only provides the parameter and return specification, leaving the agent to infer when this tool is appropriate.
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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds the source URL and the scope '所有股票的历史分红数据' (all stocks' historical dividend data), which clarifies the data scope. However, it doesn't disclose potential pitfalls like rate limits, data freshness, or the fact that it returns ALL stocks (which could be a large dataset). For a tool with annotations covering safety, this is acceptable 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title, but it includes a raw URL that takes up space without explaining its relevance to the agent. The docstring-style 'return' and 'rtype' lines are succinct but add minimal value beyond the description. It's efficient but slightly cluttered with the URL and lacks a clean separation of purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero params) and annotations cover safety, so the description doesn't need much. However, it doesn't describe the output schema or columns, which would help the agent understand what data comes back. Given the existence of sibling tools like stock_history_dividend_detail, it would be beneficial to clarify whether this returns aggregate or detailed data. The description mentions 'all stocks', but the agent might need to know if it can filter by stock or date. It's adequate for a zero-param tool but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. Since there are no parameters to document, the description doesn't need to explain any. The baseline for zero parameters is 4, and the description correctly indicates no input is needed beyond calling the function. It doesn't add detail about return columns, but that's not required for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the source (新浪财经-发行与分配-历史分红), provides a URL, and indicates the return type (all stocks' historical dividend data as a pandas DataFrame). It clearly identifies the tool as a read-only data retrieval for dividend history. However, it lacks a comparison to sibling tools like stock_history_dividend_detail, stock_dividend_cninfo, or fund_fh_em, so it doesn't fully distinguish itself from similar dividend-related functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a specific stock code) or scenarios where this tool is preferred over stock_history_dividend_detail or stock_dividend_cninfo. The description only states what it does, not when to use it.
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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal behavioral context: it reveals the data source is THS (同花顺) and the return type is a DataFrame. It does not disclose pagination, column contents, or any rate limits. Since annotations already cover safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes a useful example URL, param doc, and return type in a few lines. No filler, but the structure is a bit terse and mainly a docstring copy. It earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter and clear annotations. The description gives enough to call it (symbol only) but lacks context on the returned DataFrame fields and how this tool compares to sibling dividend tools. Given its simplicity, a 3 is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions on parameters), so the description carries the burden. It states 'symbol: 港股代码' (HK stock code) and provides an example URL with HK0700, which helps clarify the format. However, it doesn't specify whether the symbol should include leading zeros or the exchange prefix. The example implies a 4-digit format but doesn't explicitly say so. Baseline for one undocumented param is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the source (同花顺/THS), market (港股/HK stocks), and subject (分红派息/dividend distribution). It clearly identifies a specific resource per symbol. However, it does not explicitly distinguish itself from the many sibling tools like stock_hk_dividend_payout_em, stock_fhps_ths, or stock_history_dividend, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives is provided. The description only shows a sample URL and parameter type. There is no mention of when THS dividend details should be preferred over East Money (EM) or other dividend tools, nor any exclusions or prerequisites.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds some value by specifying the return type (pandas.DataFrame) and the source URL, but it does not disclose additional behavioral traits such as data freshness, pagination, or rate limits. Since annotations cover the core safety aspects, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a title, source URL, and param/return docstrings. It avoids unnecessary fluff. The URL might be considered extra but serves as a useful reference. No redundant sentences are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool, the description provides the return type and param meaning, which is adequate for a basic call. However, it does not describe the contents of the DataFrame (columns or dimensions of growth comparison) or the meaning of the default symbol '03900'. Since there is no output schema, more detail about the return structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a docstring for 'symbol' as '股票代码' (stock code), which adds meaning beyond the schema's bare string type and default value. However, it does not specify the expected format (e.g., leading zeros, 5-digit HK code) or how to obtain valid symbols. With schema description coverage at 0%, the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (HK stock industry comparison) and the specific aspect (growth comparison) via the Chinese title '东方财富-港股-行业对比-成长性对比'. It distinguishes from sibling tools like stock_hk_valuation_comparison_em and stock_hk_scale_comparison_em. However, it lacks an explicit verb like 'get' or 'fetch', relying on the implicit return type to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions, prerequisites, or scenarios where another tool (e.g., stock_zh_growth_comparison_em for A-shares) would be more appropriate. The only context is the title and URL, which imply the data source but not usage conditions.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which conveys the safety profile. The description adds the source URL and the fact that it returns a DataFrame, but discloses no additional behavioral traits such as pagination, data granularity, or rate limits. With annotations covering the core safety 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is written as a compact docstring with a title line, URL, parameter/return annotations, which is reasonably sized for a one-parameter tool. However, it lacks a plain-language opening sentence and front-loads the Chinese title, making it less immediately scannable. Each line contributes something, but the structure is not optimally tailored for an AI agent's quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 annotations indicating a safe read operation, the description gives enough to invoke it. Yet it does not describe the contents of the returned DataFrame beyond '股本变动', nor does it explain the relationship to sibling tools like stock_share_change_cninfo, leaving some ambiguity for selection and output expectation. It is adequate but incomplete for a tool with many close relatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with a default, providing no descriptions. The description compensates by listing the valid choices: {"深市主板", "沪市", "创业板", "科创板", "北交所", "全部"}, which adds meaningful semantic value beyond the schema. It also documents the parameter type and return type, though it does not explain what each market choice specifically filters or the exact output columns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves '股本变动' (capital stock changes) from CNInfo's data center, and the Chinese title and URL clarify the source. It is specific about the resource (thematic statistics for shareholders' equity) and the return type (pandas.DataFrame). However, it does not explicitly differentiate itself from sibling tools like stock_share_change_cninfo or stock_hold_num_cninfo, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_hold_control_cninfo or stock_share_hold_change_sse. It only lists the parameter choices and the return type, with no context about use cases, prerequisites, or exclusions. Given the large number of related stock-hold/share tools, this lack of usage guidance is a notable gap.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the main safety profile. The description adds that it returns a pandas.DataFrame, which is useful, but does not disclose potential rate limits, pagination, or any other behavioral nuances. Since annotations carry the safety burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and essentially repeats the title, then adds a URL and return type. It is not a well-structured sentence or paragraph; it reads more like metadata fragments. While short, it lacks the flow that would make it a polished description, though it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description should explain what data is returned beyond the vague title. It states the return type (pandas.DataFrame) but does not list columns, time range, or any caveats. For a straightforward data download tool, this is acceptable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, 0 params receives a baseline of 4 because there is no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (东方财富网/数据中心) and specific content (董监高及相关人员持股变动明细), making the tool's purpose reasonably clear. It distinguishes itself from the sibling tool stock_hold_management_detail_cninfo by explicitly referencing the East Money URL, though it lacks an explicit verb like 'fetch' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the CNINFO variant or any context for choosing this specific data source. Users must infer usage solely from the tool name and URL.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, effectively covering the safety profile. The description adds the source URL and return type, but does not disclose edge cases, rate limits, or any deeper behavioral traits beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly compact but lacks a structured summary sentence. It leads with a URL and uses docstring-style parameter listings, which conveys necessary information but could be better organized with a concise one-line overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description covers the parameters and return type. However, it does not specify the columns in the DataFrame or provide example usage, leaving some ambiguity about the exact output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by documenting all three parameters: symbol with its allowed choices, time with choices and default, and date as '日期'. This adds significant meaning beyond the schema, though the exact date format is only implied by the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('百度股市通-热搜股票') and includes the source URL and return type, making it evident this retrieves Baidu's hot search stock list. However, it lacks an explicit action verb and does not contrast with sibling hot-rank tools like stock_hot_rank_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative hot stock tools. The parameter choices are listed, but there is no mention of alternatives, exclusions, or when to prefer this over similar tools in the sibling set.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is useful context, but doesn't add details like pagination, data freshness, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with title, URL, params, and return type. It is compact and front-loaded with the title. The URL adds some noise but doesn't detract significantly from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify what the returned data contains. It only states '指定 sector 和 indicator 的数据' (data for specified sector and indicator), which is vague about columns or content. The title implies stock rankings, but the return semantics are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists the allowed values for both market and indicator, providing the necessary enumeration. However, it doesn't explain the semantics of each choice (e.g., difference between 北向 and 沪股通) and uses 'sector' instead of 'market' in the return description, causing slight ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: 东方财富-数据中心-沪深港通持股-个股排行 (Eastmoney Data Center - Stock Connect Holdings - Individual Stock Ranking), making the tool's purpose clear. However, it lacks an explicit verb like 'get' or 'fetch', and doesn't explicitly distinguish from sibling tools, though the name and context are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites. The description only lists parameter choices, offering no context on use cases among the many similar stock_* sibling 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 annotations declaring readOnlyHint=true, destructiveHint=false, and idempotentHint=true, the safety profile is covered. The description adds the return type (pandas.DataFrame) and the timeout parameter constraint, providing some context, but it does not describe output content, error behavior, or data source specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a title and URL. The docstring-like format is efficient, but the :param/:type lines are somewhat redundant with the schema and the overall layout is not optimized for an AI agent's quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only says 'returns pandas.DataFrame'. It does not specify what fields or information are included, leaving the agent unable to predict the actual data. This is a significant gap for selecting among the many stock-information sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains 'symbol' as a stock code (股票代码) and clarifies that timeout is a positive float or None, which adds meaning beyond the JSON schema's bare type declarations. However, the timeout description is still a type constraint rather than its behavioral role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns '股票信息' (stock information) for an individual stock from Eastmoney, with a sample URL. This is a clear purpose but not very specific about what 'stock information' includes, and it doesn't explicitly differentiate from sibling tools like stock_zh_a_spot_em or stock_individual_basic_info_xq.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides parameter documentation and a URL; it does not mention intended scenarios, prerequisites, or why an agent should choose this over sibling 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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds that the source is Sina Finance and the return is a pandas DataFrame, but does not disclose additional behavioral traits such as pagination, rate limits, or data range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with title, source URL, parameter documentation, and return type. It is concise and easy to parse, though the URL line is somewhat extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter read-only tool. The description provides the return type (DataFrame) and what it returns (rating records). However, it lacks details about the returned columns and the exact symbol format, which could be important for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It specifies 'symbol' is a stock code (股票代码) of type str, which adds meaning. However, it does not clarify whether the format requires an exchange prefix (e.g., 'sz000001' as in the URL) or just the numeric code (default '000001').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns stock rating records for a specific stock from Sina Finance's institutional recommendation pool. It uses the URL example to illustrate the data source and distinguishes itself from siblings like stock_institute_recommend by focusing on per-stock rating records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only documents the parameter and return type, with no mention of use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the source URL and return type, which provides some context, but it does not disclose any caveats like required symbol prefix format ('sz'/'sh'), date format, or behavior for invalid dates. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title. It includes the source URL, parameter docs, and return type in a docstring format. The URL is somewhat verbose but serves as an example. No unnecessary prose; every line contributes to understanding the tool's interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values; it does mention '分时数据' and 'pandas.DataFrame'. However, it omits critical invocation details like the exchange prefix in the symbol (e.g., 'sz', 'sh') and the exact date format (YYYYMMDD), which are only inferable from defaults. For a simple tool, the description is adequate but incomplete for a first-time user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides parameter names and types (symbol: 股票代码, date: 交易日) but does not explain format requirements. The URL example shows symbol='sz000001', and the schema defaults give date='20240321', which are helpful but not explicitly described. The description adds partial semantic value but leaves format ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '新浪财经-日内分时数据' (Sina Finance intraday minute data) and indicates a data fetch with a URL and return type. This clearly conveys the tool's function of retrieving intraday stock data. However, it does not explicitly differentiate from sibling tools like stock_intraday_em or stock_zh_a_hist_min_em, relying mainly on the 'sina' in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 distinguishing use cases, such as preferring it for Sina-specific data or its unique attributes. There is no exclusion or alternative reference.
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 cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the source URL and return type but does not disclose other behavioral traits like data scope, freshness, rate limits, or any quirks of the returned DataFrame. This is adequate for a simple read-only tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a source title, URL, and return type in a docstring-like format. It has no fluff, but it repeats the title from annotations and does not provide a structured narrative for an AI agent, so it is not maximally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the returned DataFrame contains. It only repeats 'IPO辅导信息' without specifying columns, update frequency, or data scope. For an agent to use the data meaningfully, it needs more detail about the return structure and content limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is trivially complete (100% coverage). Since there are no parameters to describe, the baseline of 4 applies; the description does not need to compensate for any parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source ('东方财富网-数据中心-新股数据-IPO辅导信息'), the URL, and the return type ('IPO辅导信息', pandas.DataFrame). This makes the purpose clear for a data-fetching tool, though it relies on the same terminology as the tool name and title rather than a distinct verb phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 compared to sibling tools. It only states the source and return type, with no context about selection criteria, alternatives, or preconditions.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context by specifying the return type as pandas.DataFrame and the parameter as a trading day, but it does not disclose column details, pagination, or data source quirks. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the title. It includes a source URL and structured docstring lines for param/return. There is minor redundancy (the title repeats in the 'return' line), but overall it is concise and well-organized for the limited content it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description is mostly adequate but thin. It explains the parameter and return type, yet it fails to clarify the DataFrame columns, how this tool differs from the many similar LHB siblings, or any date formatting/rules. The strong annotations partially compensate, but the lack of differentiation in a crowded sibling set leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate. It defines 'date' as '交易日' (trading day) and gives its type as str, which adds semantic meaning beyond the bare schema. The default value '20240222' implies a YYYYMMDD format, but this is not explicitly stated, and no further details about required vs optional behavior are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as '龙虎榜-每日详情' (Dragon-Tiger List daily details) and provides a source URL. This conveys that the tool fetches daily LHB details, and the name includes 'sina' to distinguish from similar EM-based tools. However, it lacks a verbose action verb and does not explicitly differentiate among the many sibling LHB 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/5Does 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 any exclusions, prerequisites, or comparisons to sibling tools like stock_lhb_detail_em or stock_lhb_ggtj_sina. The only context is the source URL, which does not help an agent choose between similar LHB 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds the return type pandas.DataFrame but does not disclose any potential quirks, such as whether data is available for all historical dates or whether the summary includes multiple rows per date. This is acceptable for a simple read tool but adds limited 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the main purpose stated in the first line and a structured docstring for parameters and return type. It avoids unnecessary elaboration, though the docstring could be seen as somewhat repetitive given the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter data retrieval tool with strong annotations, the description is minimally adequate. However, there is no output schema, and the description does not list the columns or structure of the returned DataFrame, nor provide an example call. An agent would need to infer data granularity and date handling from the default value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one 'date' parameter with zero description, but the docstring clarifies it is a trading day (交易日). It does not specify the expected format (though the default '20260721' implies YYYYMMDD) or any constraints. The description partially compensates for the schema's lack of documentation, but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Beijing Stock Exchange margin trading summary data, with the title and first line specifying '融资融券汇总'. The name and description together distinguish it from related siblings like stock_margin_detail_bse (detail) and other exchange-specific margin tools, though it lacks an explicit verb like 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives. No mention of related tools such as stock_margin_detail_bse or stock_margin_sse, nor any context about typical use cases. The description only implies a single-date query without explaining how the date should be formatted or what happens if it's invalid.
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 (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already establish the safety profile. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose behavior like date format constraints, pagination, or data availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the title and URL, followed by parameter documentation in a standard docstring format. No unnecessary words, though it could be more narrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter data retrieval tool, the description adequately states the source, return type, and basic parameter meaning. However, it lacks usage differentiation from sibling tools and does not mention any caveats about data format or availability, making it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'date' parameter (0% coverage), so the description must compensate. It does add the semantic label '交易日期' and type 'str', but stops short of explaining the expected format (e.g., YYYYMMDD), relying on the default value as an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (SSE margin trading detail) and provides a source URL, distinguishing it from similar tools for other exchanges (SZSE/BSE). However, it lacks an explicit verb like 'get' or 'list', relying on the noun phrase '融资融券明细' to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings such as stock_margin_sse or stock_margin_detail_szse. The description does not mention exchange-specific scope or prerequisites, leaving the agent to infer usage solely from the name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific exception behavior (raises Exception if server data cannot be parsed) and states the return type. This is useful but limited; no mention of rate limits, authentication, or response content details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with labeled docstring sections and a URL. It front-loads the title and includes only essential technical details. The URL, while not strictly necessary, is not excessive. No redundant or vague prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers input, return type, and error behavior. However, it does not specify the exact content of the company profile (column names, fields), market coverage (A-shares, B-shares, etc.), or any data update frequency. Given the lack of output schema, more detail on return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It defines 'symbol' as '股票代码' (stock code) with type str, which is basic but meaningful. However, it lacks details like format (e.g., 6-digit code), exchange-specific examples, or any guidance beyond the raw term. The description adds some value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '公司概况' (company profile) for an individual stock from CNINFO, with a return type of pandas.DataFrame. It does not explicitly state a verb like 'get' or 'retrieve', but the return documentation implies data fetching. It doesn't explicitly distinguish from sibling tools, though the source (CNINFO) and name provide some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is purely a docstring with parameter, return, and exception details. It provides no guidance on when to use this tool versus alternatives like stock_individual_info_em or stock_hk_company_profile_em. No context about market scope (A-share, H-share) or prerequisites is given.
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 already provide readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context such as the data source URL, the requirement that 'symbol' include a market identifier (带市场标识), and the return type (pandas.DataFrame). It does not contradict annotations, but it does not disclose other behavioral traits like data range, update frequency, or potential missing data conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: source title, URL, parameter documentation with type and default, and return documentation. It is appropriately sized for a simple tool, with no redundant prose. The main content is front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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) and the presence of safety annotations, the description covers the essential information: what data is retrieved, the parameter requirement, and the return type. However, it does not clarify the meaning of '报告期' (report period) in terms of which specific reporting periods are included, nor does it address possible data availability issues or the structure of the returned DataFrame. This is satisfactory but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a single parameter 'symbol' with a default value and no description (schema coverage 0%). The description compensates by explaining that the symbol must include a market identifier (带市场标识) and provides a default example (SH600519). This gives the agent essential information for parameter formatting, but it does not explain the full set of valid market prefixes or the exact format expected, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving East Money stock income statement (profit sheet) data for the report period, with a URL for reference. It distinguishes from siblings like the quarterly or yearly variants by explicitly stating '报告期' (report period) in both name and description. However, it lacks a direct verb like 'get' or 'retrieve', relying on the implicit function of the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus its siblings (e.g., stock_profit_sheet_by_quarterly_em, stock_profit_sheet_by_yearly_em, or delisted versions). The only context is the 'report period' label, which implies a specific period type, but no alternatives or exclusions are mentioned. The description does not help an agent choose among the many related financial statement 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?
Annotations already declare readOnly, idempotent, non-destructive. The description adds only the return type (pandas.DataFrame) and URL, but no behavioral context like pagination limits, data freshness, or potential network failures. With annotations covering safety, still minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three lines including title, URL, and return type. No filler, well-structured docstring format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-param data fetch, the description gives source and return type, but lacks details about DataFrame columns, data update frequency, and exact contents beyond '量价齐升'. Without an output schema, this leaves the agent guessing about the data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, so description need not explain params. It implicitly indicates no inputs are required, which is consistent. Baseline of 4 for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the source (THS Data Center) and specific screening criterion (量价齐升, volume-price increase), with a URL and return type. It distinguishes from sibling rank tools by specifying this is the ljqs (量价齐升) ranking, though it lacks an explicit verb like 'fetch' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs other stock_rank_* tools. Sibling tools like stock_rank_cxg_ths or stock_rank_xstp_ths exist, but the description doesn't differentiate use cases. No exclusions or context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the source URL and a return type of pandas.DataFrame, but does not disclose any additional behavioral traits such as data freshness, row limits, or the exact meaning of '连续上涨' (e.g., number of days). This is slightly above minimal but still lacks meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, front-loaded with the title, and includes only a URL and return type docstring. It wastes no words and is appropriate for a zero-parameter data retrieval tool. However, the URL line could be considered slightly arbitrary and the overall structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values. It only says '连续上涨' (consecutive gains) without specifying the columns (e.g., code, name, days of rise), sorting, or data scope. The lack of detail about the DataFrame structure makes it incomplete for an agent to predict what data will be returned. Annotations provide safety context but not output semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema correctly reflects this with an empty properties object. Since there are no parameters to explain, the baseline of 4 applies. The description adds no parameter information but is not required to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description explicitly identify the tool as the THS Data Center page for '连续上涨' (consecutive gains), along with a direct URL. This clearly indicates it fetches a ranking of stocks with consecutive rises, distinguishing it from sibling rank tools by the specific lxsz (连涨) indicator. However, it does not explicitly state the action verb like 'list' or 'get', and relies heavily on the name/title to convey the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides no context on use cases, prerequisites, or comparison with siblings such as stock_rank_cxd_ths or stock_rank_lxxd_ths. It simply states the data source and return type without explaining scenarios where this ranking is appropriate.
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 already state readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds a return type (pandas.DataFrame) and the source URL, but does not disclose additional behavioral traits such as data freshness, pagination, or potential errors. It does not contradict the annotations, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with URL, parameters, and return type. It is efficient with no redundant text, though the layout is more technical than natural language, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is mostly adequate. It explains the source, parameters, and return type, but does not describe the output columns or data granularity, leaving some ambiguity about the exact contents of the returned DataFrame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It fully describes the market parameter with a mapping of Chinese labels to codes, but the period parameter is vague ('最近四期的财报') with no explicit valid values, and it conflicts slightly with the schema default '2021年报.' Thus it adds meaningful but incomplete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (CNInfo scheduled disclosure data) and the function (returns data for specified market and period), as evidenced by the URL and parameter/return documentation. However, it lacks an explicit action verb like 'retrieve' or 'list,' and does not explicitly differentiate from sibling tools beyond the resource URL, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists parameters and return type, with no mention of eligible use cases, exclusions, or related tools. This is a clear gap.
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 annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds the source URL and return type (DataFrame). It does not contradict annotations, but it also does not disclose any additional behavioral traits such as pagination, rate limits, or error handling. This meets the lower bar set by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear structure: source, parameters, and return type. Every line provides useful information, and there is no fluff. It is not overly long given the need to document two parameters and the return type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only data fetch with only 2 parameters and no output schema, the description covers the source, symbol enums, date format, and return type. It is largely complete, but the minor date-format inconsistency and lack of clarity on output columns keep it from being a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by listing the symbol choices and explaining the date format with examples. However, the date format in the description (with dashes, e.g., 2020-12-31) conflicts with the schema default (without dashes, e.g., 20210331), creating ambiguity. This prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves fund holdings data from Eastmoney's Data Center, specifying the source URL and the available symbol categories. However, it does not explicitly differentiate itself from sibling tools like stock_report_fund_hold_detail, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides allowed parameter values and date formats, which is a form of usage guidance. However, it gives no context on when to choose this tool over alternatives, nor any exclusions or prerequisites. This is a significant gap given the large sibling list.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and the source URL, providing some behavioral context. However, it does not disclose details like pagination, data volume, or potential rate limits, so it adds limited value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with clear sections for source, parameter, and return, front-loaded with the title and URL. Every line earns its place, though the URL could be seen as extraneous. It is well-structured and appropriately sized, though not exceptionally compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and the description explains the source and return type, which is useful. However, with no output schema, it does not describe the DataFrame columns or what the research report data contains, leaving the agent guessing about the result structure. The absence of any mention of data range, filtering, or pagination makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden for parameter meaning. It documents ':param symbol: 个股代码' (individual stock code), which clarifies the purpose of the single parameter, and the schema's default '000001' suggests a 6-digit A-share code. Yet it omits format specifics (e.g., exchange prefix, applicable markets), leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (东方财富网-数据中心-研究报告-个股研报 = East Money Data Center individual stock research report) and includes a URL, which clearly scopes it to a specific data source and type. However, it lacks an explicit verb like 'fetch' or 'return', though the docstring's ':return: 个股研报' implies retrieval, so it stops short of a fully specific verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 describes the source and parameter, without mentioning any exclusions, competitor tools, or specific use cases. This leaves the agent to infer usage purely from the name and source.
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 already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a useful source URL and indicates a pandas DataFrame return type, but it does not disclose behavioral details such as pagination, data scope, date limits, or the exact contents of the returned DataFrame. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's Chinese title and source URL, followed by concise param/return docstring lines. It contains some redundancy with the annotations title and schema type information, but overall there is no filler or excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only data retrieval tool, the description is minimally usable: it identifies the source, parameter, and return type. However, with no output schema, it fails to describe the returned DataFrame's columns or semantics, and it does not explain what '解禁批次' contains or how this tool relates to the many restricted-release sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the burden of explaining 'symbol'. It provides the Chinese meaning '股票代码', confirms the type as str, and shows an example via the URL '600000'. This adds modest meaning beyond the raw schema, but it does not explain code format, valid values, or the default behavior when the parameter is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data domain and source through the Chinese title '东方财富网-数据中心-个股限售解禁-解禁批次' and the return statement '个股限售解禁', making it evident that this tool fetches restricted-share release batches for individual stocks from Eastmoney. However, it lacks an explicit verb like '获取/查询' and does not directly differentiate itself from sibling tools beyond the implied 'em' source and the given URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_restricted_release_queue_sina, stock_restricted_release_detail_em, or stock_restricted_release_summary_em. The description only states the data source, a single parameter, and the return type, leaving usage context and exclusions entirely unaddressed.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds that data comes from East Money and returns a pandas DataFrame, but it does not disclose potential network dependency, data freshness, or pagination behavior. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a clear docstring structure: title, URL, parameter definitions, and return type. It is front-loaded with the title and URL, and each line serves a purpose. Some lines like ':type' are redundant but not harmful, keeping it reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values more thoroughly. It only says the return is 限售股解禁 as a DataFrame, without specifying columns, granularity, or how this summary differs from detail tools. Annotations cover safety, but the description lacks enough context for an agent to fully understand the data structure and use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents each parameter in Chinese: symbol (target market) with explicit allowed values, start_date (start time), and end_date (end time). This adds meaning beyond the bare schema. However, the date format is ambiguous: the URL example uses hyphens (2022-11-08) while schema defaults use YYYYMMDD (20221209), which could lead to incorrect usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool provides restricted share release (限售股解禁) summary data from East Money's data center, with a URL and return type. The tool name includes 'summary', distinguishing it from similar tools like stock_restricted_release_detail_em, though the description itself doesn't explicitly state the verb 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_restricted_release_detail_em, stock_restricted_release_queue_em, or stock_restricted_release_stockholder_em. It only documents parameters and the source URL, leaving usage context entirely implicit.
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 already declare readOnly, idempotent, and non-destructive, which cover the safety profile. The description adds the data source (East Money), a URL, and the return type (pandas DataFrame), providing some context. However, it does not disclose details like date ranges, pagination, or data update frequency, so it adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite short and includes a title, URL, and a brief docstring with parameter and return info. It is structured and avoids waste, but the first line is more of a label than a concise summary sentence. It could be improved by front-loading a clear one-sentence purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with annotations covering safety and idempotency, the description provides the source and parameter meaning. However, the return description is vague ('xx行业个股资金流') and does not clarify the exact structure of the DataFrame, date range, or whether the data is per-stock or industry-level. Without an output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a 'symbol' parameter with 0% coverage, so the description must compensate. The description provides ':param symbol: 行业名称', adding that the parameter is an industry name, which is helpful. However, it does not specify valid values, format (e.g., Chinese name), or how to discover industry names, leaving the parameter semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching industry historical capital flow data from East Money, with a specific URL and parameter for industry name. However, the return description 'xx行业个股资金流' is slightly ambiguous—it could mean individual stock flows within the industry rather than the industry's aggregate historical flow. The tool name and title help disambiguate to historical sector fund flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like stock_sector_fund_flow_rank or stock_sector_fund_flow_summary. The name implies 'hist' means historical, but the description does not state this or provide any 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context: the data source URL, return type (pandas.DataFrame), and indicator choices (今日/5日/10日). However, it does not disclose potential data latency, pagination, or any limitations, which would be valuable for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is reasonably compact but includes redundant elements: the title line duplicates the description's first phrase, and the URL may not be essential for an agent. The docstring-style formatting is clear and front-loaded, but the extra URL and repeated title make it slightly cluttered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool, the description covers purpose, parameters, and return type, which is adequate for basic invocation. However, it lacks explicit usage context, differentiation from close siblings (e.g., stock_sector_fund_flow_hist, stock_sector_fund_flow_rank), and any examples or edge-case handling, leaving the agent to infer when this tool is the best choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It provides clear semantics: symbol is '行业名称' (industry name) and indicator is a choice of {'今日', '5日', '10日'}. This fully compensates for the missing schema descriptions, though it could be more explicit about the format of symbol values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('行业资金流' - industry fund flow) and the specific output ('xx行业个股资金流' - individual stock fund flows for a given industry). The verb is implied but the scope is specific, and the resource distinguishes it from sibling tools like stock_sector_fund_flow_rank and stock_sector_fund_flow_hist, though it does not 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 Guidelines2/5Does 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 use cases, exclusions, or which sibling tools serve different purposes. The description only enumerates parameters and return type, leaving selection decisions to the agent without contextual hints.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and the return type (pandas.DataFrame), which is useful but minimal. It does not disclose additional behavioral traits like rate limits, data freshness, or scope of the returned data. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first line and the ':return:' line are essentially identical. The URL and ':rtype:' add some structure, but the repeated phrase makes it less concise than it could be. It is a mix of a title, URL, and docstring-style return information without a clear front-loaded summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter real-time quote tool, the description provides the data source and return type, which is somewhat helpful. However, since there is no output schema, the description could explain more about the returned data, such as the list of AH stocks or columns. It does not mention whether this is a full snapshot or if any filtering applies, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics (vacuously at 100%). Per the rubric, a baseline of 4 is appropriate for 0 params, and the description does not need to add parameter details. The description provides no parameter information, which is fine since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning AH share price comparison real-time quotes from East Money (东方财富网). The included URL and the word '实时行情' (real-time quotes) specify the resource and type of data. It distinguishes from similar siblings like stock_zh_ah_daily (historical) and stock_zh_ah_spot (likely a different source) through the _em suffix and East Money URL, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_zh_ah_spot, stock_zh_ah_daily, or stock_zh_ab_comparison_em. It does not state any context, prerequisites, or exclusions. The only clue is the East Money URL, which is not explicit usage guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that the return is a pandas DataFrame and identifies the data source, but does not disclose any additional behavioral traits such as rate limits, symbol format requirements, or data coverage. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear param/return sections. It repeats the title in the return line but is not verbose. The URL example provides some context but could be removed for AI consumption without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only specifies the return type as pandas.DataFrame and the general content as historical tick data, but does not describe columns, date range, or any limitations. Given the tool's simplicity and strong annotations, it is adequate but leaves gaps for an agent to know the exact structure of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'symbol' parameter (0% coverage). The description explains 'symbol' as '股票代码' (stock code) and provides an example URL with 'sz300494', which gives some context. However, it does not explicitly state the required exchange prefix format (e.g., 'sz' for Shenzhen, 'sh' for Shanghai), leaving potential ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns '历史分笔数据' (historical tick data) from Tencent Finance, and the URL shows a specific example. This distinguishes it from sibling tools like stock_zh_a_hist_tx, which provide K-line data. However, the verb is implicit and '分笔' is not explained for agents unfamiliar with the term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any conditions, exclusions, or when this might be preferred over other stock historical data tools, which is a significant gap given the large number of sibling 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds that the result is a pandas DataFrame, but provides no detail on the columns, data source behavior, or potential limitations, leaving room for more 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, leading with a clear title, then a reference URL, and a minimal docstring for the parameter and return value. It is front-loaded and every line adds some value, though the URL could be seen as clutter for tool selection purposes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, no output schema, and simple read-only annotations, the description is adequate for basic usage. However, it does not specify what columns or metrics the growth comparison returns, and the URL's example code is not explained, leaving some ambiguity for an AI agent deciding if this is the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists 'symbol' with a default but no description (0% coverage). The description compensates with ':param symbol: 股票代码' (stock code), and the URL shows an example 'SZ000895', which clarifies the expected format reasonably. However, it does not explain exchange prefixes or error cases, making the guidance minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Eastmoney's growth comparison (成长性比较) for peer stocks, with a direct URL and a stated return type. It distinguishes itself from sibling tools like scale or valuation comparisons, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many similar stock comparison tools (e.g., scale, valuation, or Hong Kong growth comparisons). Context is implied only through the name and URL, with no explicit exclusions or alternatives.
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 already cover read-only, non-destructive, and idempotent behavior. The description adds source (Baidu) and data type (stock review votes) but does not disclose potential quirks like data freshness, column contents, or response details. It partially supplements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but loosely structured, mixing a title, URL, and docstring-style parameter definitions. Every line carries information, but it lacks a coherent narrative and the URL may be unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description plus annotations are sufficient to understand basic usage. However, without an output schema, it only says '投票数据' without explaining the DataFrame's structure or any caveats, so completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides Chinese labels for both parameters: symbol as 股票代码 and indicator with allowed values {'指数', '股票'}, which the input schema lacks. The example URL also hints at how the symbol is used, adding meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves A-share or index stock review voting data from Baidu (百度股市通). This is specific enough to distinguish it from sibling tools that focus on prices, valuations, or other financial metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 gives a title and parameter documentation, with no context for selection criteria or exclusion of other stock data 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is clear. The description adds the source URL and the date parameter meaning, but it does not disclose behavior such as handling of invalid dates, empty results, or data update frequency. Given the strong annotation coverage, the additional context is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with source, URL, parameter, and return sections. It repeats the title from annotations in the first line, but the overall length is reasonable and information is easy to scan. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema. The description explains the input and return type (DataFrame), but it does not describe the columns or content of the returned DataFrame, nor does it provide an example call. Since the output schema is absent, the description should compensate more fully for what the data covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must carry the parameter meaning. It states ':param date: 交易日' (trading day) and ':type date: str', which clarifies that the input is a trading date string. However, it does not specify the format beyond the default value '20241011', nor does it mention optionality or consequences of omitting it. For a single parameter, this is adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '跌停股池' (limit-down stock pool) from East Money's limit-up board section, and the docstring explicitly states the return is a pandas DataFrame of that pool. It distinguishes from sibling tools by name (dtgc) and the '跌停股池' term. However, it lacks an explicit action verb like 'fetch' or 'get', relying on the docstring's :return: clause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many related stock_zt_pool_* siblings. It does not state that this is for limit-down pools specifically or mention any exclusions. The 'dtgc' suffix and '跌停股池' term imply it, but no explicit usage direction is given.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type but does not disclose any behavioral nuances such as rate limits, network dependency, or error handling. With annotations covering safety, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a structured docstring format with title, URL, param, and return fields. It is front-loaded with the title and source. The first line is redundant with the annotations title, which slightly detracts, but overall it is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no output schema, so the description must clarify the return value. It vaguely states '主营介绍' (main business introduction) and returns a DataFrame, but does not describe columns, data granularity, or example content. The hardcoded URL for stock 000066 could mislead an agent into thinking the tool only works for that stock. No usage guidance is provided despite many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists 'symbol' as a string with a default. The description adds that symbol is a 股票代码 (stock code) and provides an example URL using '000066', giving meaningful context beyond the bare schema. However, it does not specify whether the code needs zero-padding, exchange prefix, or other formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides '同花顺-主营介绍' (THS main business introduction), with a URL indicating the source and a return type of pandas.DataFrame. It clearly identifies the resource and operation, though it could be more explicit about the specific fields or content of the returned data. It is distinguishable from siblings by the 'ths' suffix and Chinese name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other stock-related tools such as stock_zygc_em or stock_financial_abstract. The description lacks any context about data source preference, use cases, or alternatives.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type (pandas.DataFrame), but provides limited additional behavioral detail, such as data freshness or exact contents. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but feels like a raw docstring extraction with a Chinese title, a URL, and return tags. The URL is not directly actionable for an agent, and the structure is fragmented, though it is front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool, the description is adequate for basic invocation, but it does not describe what the returned DataFrame contains (e.g., columns, codes, names). The absence of an output schema increases the need for such detail, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the input schema already covers all needed information. The description adds no parameter semantics, but none are required; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool as '乐咕乐股-申万三级-分类' (Legulegu Shenwan Level 3 Classification) and notes it returns a pandas DataFrame. This identifies the resource and function, and the 'third' in the name distinguishes it from siblings like sw_index_first_info and sw_index_second_info, though it lacks an explicit action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to use this tool, what it is useful for, or when to prefer alternatives such as sw_index_first_info or sw_index_second_info. The agent receives no guidance beyond the label.
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 already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the exact formula and required columns, which is useful behavioral context. However, it does not disclose edge cases, error conditions, or the exact output format beyond returning a DataFrame, which is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repetitive, with the formula presented in both Chinese and English comments, plus external links and a paper reference. This adds noise and reduces readability. The essential information could be conveyed in two or three concise sentences, making the current length unjustified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the formula, input requirements, and return type, but it does not specify the output column name, how to pass data in the JSON format expected by the schema, or how missing/invalid data is handled. The formula itself contains a minor discrepancy (di listed as either ln(Li/Oi) or Li/Oi) that could confuse the agent. With no output schema, these omissions make the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for the 'data' parameter, and the description only says it should be a pandas.DataFrame with OHLC columns. The schema expects an array or object, but the description does not explain this mismatch or how to structure the data as JSON. It lists required columns, providing some value, but fails to bridge the DataFrame-to-JSON gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as calculating Yang-Zhang Realized Volatility from OHLC data, with a specific verb ('计算') and resource. It includes the full formula and differentiates from sibling tools that fetch data rather than compute. The title and description align, making the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a calculation tool that requires OHLC data, but it does not explicitly state when to use this tool versus alternatives like rv_from_futures_zh_minute_sina or rv_from_stock_zh_a_hist_min_em. It provides no when-to-use or when-not-to-use guidance, so the agent must infer based on context.
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 already indicate read-only, idempotent, non-destructive behavior. The description adds limited extra transparency by specifying the data source URL and the return type (pandas.DataFrame). It does not describe edge cases, potential failures, or detailed output structure, but given the annotations cover safety, the added context 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured: it begins with a redundant title line, includes a broken sentence ('指定之间段之间的空气质量数据'), and mixes Chinese and English unevenly. The docstring-style parameter sections are organized, but the front matter contains unnecessary repetition and awkward phrasing, making it less concise and clear than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core aspects: purpose, parameters, return type, and source URL. However, without an output schema, it gives only a high-level description of the return ('观测点空气质量') and does not specify columns or metrics. For a simple retrieval tool with three string parameters, this is acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing parameter types, format examples for dates, and a lookup method for city values. This is highly valuable for an agent to construct valid calls. The only minor gap is not explicitly stating the date format beyond examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving air quality data for each monitoring point in a specific city within a date range. The phrase '细化到具体城市的每个监测点' highlights the per-station granularity, which distinguishes it from sibling tools like air_quality_hist or air_quality_rank. However, it lacks an explicit verb like 'get' or 'fetch', and the phrasing is somewhat awkward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied through the description of per-station data, and the parameter doc for 'city' explicitly instructs users to call ak.air_city_table() to obtain valid city values. No explicit alternatives or exclusions are provided, making it unclear when to choose this tool over sibling air quality 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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover the safety profile. The description adds the source URL and return type, but no further behavioral traits such as pagination, rate limits, or authentication needs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core information: the source, the endpoint URL, and return type. However, the Chinese title is repeated verbatim in the first line and then again in the 'return' line, making it slightly redundant though not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with rich annotations, the description is adequately complete: it names the exact data (ABS plan disclosure), provides the source URL, and states the return type (pandas.DataFrame). However, it does not describe the content of the DataFrame beyond the general 'disclosure information' label, so an agent might not know exactly what columns or coverage to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The baseline for 0-parameter tools is 4, and the description appropriately includes the return type to clarify what the DataFrame contains, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (AMAC ABS public disclosure information) with a precise source URL and return type, which distinguishes it from other AMAC fund tools in the sibling list. The action is implied via the context of returning a DataFrame, though it does not use an explicit verb like 'retrieve' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. While the Chinese title clearly states the specific data source, there is no mention of use cases, prerequisites, or comparison with similar AMAC tools like amac_fund_info or amac_fund_sub_info.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: it specifies the source URL, the pagination semantics (start_page/end_page), and the return type (pandas.DataFrame). However, it does not disclose potential issues like rate limits, data update frequency, or what fields are included, so it only partially enriches the behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably compact: a title line, a source URL, and docstring-style parameter/return notes. The essential information is front-loaded in the title line, and the URL adds provenance context. It is structured and not verbose, but the docstring formatting is somewhat mechanical and lacks a natural-language summary sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only paginated data retrieval tool, the description provides the core behavior: fetching AMAC private equity fund product data across a page range and returning a DataFrame. However, it does not describe the DataFrame's columns or row content beyond the generic resource name, nor does it mention any pagination limits or error conditions. Given the tool's simplicity and clear annotations, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, making the description the sole source of parameter meaning. It adequately explains start_page as '开始页码, 获取指定页码直接的数据' (starting page number, get data directly for the specified page) and end_page as '结束页码' (ending page number). While it doesn't specify constraints like page ranges or that start_page should be less than end_page, it provides meaningful semantics beyond the raw schema names and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source and resource: '中国证券投资基金业协会-信息公示-基金产品-私募基金管理人基金产品' (AMAC fund product information for private equity fund managers). Although no explicit verb like 'retrieve' is used, the docstring's ':return:' line states it returns this data as a DataFrame, making the purpose evident. It distinguishes itself from siblings via the specific resource name, though it doesn't explicitly contrast with similar amac_* 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided regarding when to use this tool versus alternatives. There are many sibling amac_* tools (e.g., amac_fund_sub_info, amac_fund_abs), but the description does not mention any selection criteria, prerequisites, or exclusions. The usage context is only implied by the resource name and pagination parameters, with no direct 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the source URL and return type, but does not disclose data fields, pagination, or rate limits. With annotations, the bar is lower, but the description contributes minimal 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, containing only the title, source URL, and return type. No redundant text or repetition, so it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the returned data. It states the return type (pandas.DataFrame) and general content (私募基金管理人分类公示), but does not specify columns or detailed categories. This leaves gaps for an agent trying to understand what exactly is retrieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%. The description adds nothing about parameters because none exist, which is appropriate and matches the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific AMAC private fund manager classification disclosure and provides the source URL, making the resource clear. However, it lacks an explicit verb like 'fetch' or 'download' and doesn't distinguish this tool from sibling AMAC tools (e.g., amac_manager_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/5Does 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 are no exclusions or alternative tool mentions, so the agent receives no context for selection.
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?
Annotations already mark it as read-only, idempotent, and non-destructive, so the bar is lower. The description adds meaningful context: the data comprises daily non-parametric realized volatility measures, these are not forecasts, and the data is provided 'as is' for informational purposes. This goes beyond the annotations and helps set expectations about the data's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated with boilerplate text copied from the Oxford-Man website, including background on research, disclaimers, and 'visually explored' commentary that is not relevant to tool invocation. The useful parameter lists and symbol table are embedded in this verbose prose, and the table is truncated, making it poorly structured for quick consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter data-fetch tool, the description provides the symbol list, index list, and an availability table, which is helpful for understanding coverage. However, it lacks details on the returned DataFrame's structure (columns, date range) and is cut off mid-table, leaving the content incomplete. It does not clarify the difference from the sibling short version.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all valid values for both symbol and index, and provides a table mapping symbols to asset names and availability date ranges. This gives agents the ability to select valid parameters, though it does not explain what each index metric (e.g., medrv, rk_twoscale) represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool provides data from the Oxford-Man Realized Library, with parameters for symbol and index, and returns a pandas.DataFrame. The verb is implicit ('数据' meaning 'data'), but it is evident that it retrieves realized volatility data for a given symbol and index. It does not distinguish itself from the sibling tool article_oman_rv_short.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as article_oman_rv_short or article_rlab_rv. The table of availability dates gives coverage information but does not explain selection criteria or scenarios for choosing this 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?
Annotations already declare the tool read-only, idempotent, open-world, and non-destructive, so the description only adds the source URL and return type. It does not describe the DataFrame's columns or time range, but the annotations cover the key safety and side-effect aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the resource name and URL front-loaded, and the return type lines are minimal. However, it is fragmented into disconnected pieces (title, URL, return annotation) rather than a cohesive sentence, slightly reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and strong annotations, the description provides the essential information: the exact index name, source, and return type. It does not specify the structure of the returned DataFrame (e.g., daily values, columns), so an agent may not know exactly what data to expect, but it is sufficient for a basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is nothing to explain beyond the absence of inputs. The baseline score of 4 is appropriate because the description adds no misleading parameter information and it clarifies the return type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the exact resource: the Jisilu convertible bond equal weight index, and the ':return:' line explicitly states that this tool returns that index. It is differentiated from sibling bond tools by naming the specific index and source, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool compared to alternatives such as bond_cb_jsl or bond_index_general_cbond. There are no exclusions, alternative suggestions, or contextual cues to help an agent decide when this is the right choice.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a pandas DataFrame and gives an example URL, but it does not disclose error behavior, data scope details, or potential limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured with source URL, parameter docstring, and return type. The first line repeats the title but does not waste many words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description gives the source, parameter format, and return type. However, it does not specify what fields the '债券概况' DataFrame contains, and given the many closely related convertible bond tools, more detail on the exact output content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'symbol' parameter (0% coverage). The description compensates by explaining that symbol is a convertible bond code with a market identifier (带市场标识的转债代码) and offers a default example 'sh155255', which helps the agent construct a valid argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a convertible bond overview (债券概况) from Sina Finance, with an example URL. The resource and data type are clear, but it does not explicitly distinguish itself from sibling tools like bond_cb_profile_sina or bond_zh_cov, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other convertible bond tools, no prerequisites, and no alternatives mentioned. The description only provides parameter semantics, leaving the AI agent without context for choosing this 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the source URL and return type but does not disclose additional behavioral traits such as rate limits or data freshness. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes the essential source, URL, and return type. It follows a lightweight docstring format with clear lines, though it could be more polished as prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with strong annotations, the description is adequate. However, it does not specify what columns or data the '比价表' includes, which would help differentiate it from similar bond comparison tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. Schema description coverage is trivially 100%, and the description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (东方财富网可转债比价表) and indicates the return type (pandas.DataFrame). It is distinct from sibling tools by the '比价表' term, but lacks an explicit verb like 'get' or 'fetch', making the action implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other convertible bond tools. There are no alternatives, exclusions, or context cues to help an agent decide among siblings.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds the source URL and the list of valid symbols, which is useful, but it does not disclose output structure, data granularity (historical vs. current), or any additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, URL, and param/return sections. It is appropriately sized and front-loaded, containing no waste, though the Chinese wording is somewhat terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return structure. It only states a DataFrame of yield market data without specifying columns or whether it's historical or current. The URL points to the data source page, which helps, but the description is not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no enum or description for the symbol parameter, and the description compensates by enumerating all valid choices (中国1年期国债 through 中国30年期国债). This provides the agent the necessary vocabulary to invoke the tool correctly, though it doesn't explain the meaning of the values (e.g., maturity periods).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Sina Finance China treasury bond yield market data, with a specific resource and source. However, it doesn't explicitly differentiate from sibling bond yield tools like bond_china_yield, relying on the name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as bond_china_yield or bond_zh_us_rate. Usage is implied from the parameter list and return type, but no explicit context or exclusions are given.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the data source URL and the index hierarchy, which gives context about the data origin. However, it does not disclose behaviors like rate limits, pagination, date range coverage, or network dependency, leaving some gaps beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with line breaks separating the source, parameters, and return information. It is not overly verbose, though the first line repeats the hierarchical name which also appears in the annotations' title. The parameter lists are essential and formatted compactly. Overall, it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two optional parameters and no output schema. The description states the return type (pandas DataFrame) and the return value (新综合指数), but does not detail the DataFrame's columns, the time range of data, or how parameters affect the output. Annotations cover safety, but for a complete understanding, more behavioral and output context would be helpful. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names with defaults and no descriptions (0% schema coverage). The description compensates exceptionally by listing all valid choices for both indicator and period, which are critical for correct invocation. It does not explain the meaning of each choice, but the labels are self-explanatory in context. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific resource: 中国债券信息网-中债指数-中债指数族系-总指数-综合类指数-中债-新综合指数, along with a URL. The return type and value are also specified, making the tool's purpose evident. However, it lacks an explicit action verb like 'fetch' or 'query', but the context implies data retrieval, so it's clear but not perfectly articulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many similar bond index tools in the sibling list (e.g., bond_composite_index_cbond, bond_treasury_index_cbond). It does not mention alternatives, exclusions, or typical use cases. The only context is the specific index name, which differentiates it somewhat, but explicit usage guidance is absent.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a pandas.DataFrame, which is useful context, but does not disclose further behavioral details such as data time ranges or potential latency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing a descriptive title, a source URL, and return type information. No filler or redundancy, though it could be slightly more structured to separate the data source from the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool with good annotations, the description provides the return type and source but lacks details about the data's time period (e.g., current vs. historical) or column structure since there is no output schema. This 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain any. It does state the return type and data source, which is sufficient for a parameterless tool. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '现券市场成交行情' (spot bond market transaction quotes) from the China Foreign Exchange Trade System, with a source URL. It distinguishes from siblings like bond_spot_quote by focusing on executed transactions rather than quotes, though it lacks an explicit verb like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, exclusions, or comparison to sibling bond tools, leaving the agent to infer applicability from the resource name alone.
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?
The annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is clear. The description adds the data source URL, parameter choices, and return type, but does not disclose any additional behavioral traits such as pagination, data freshness, or potential errors. It contributes only minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear sections for URL, parameters, and return type. It is easy to scan and contains no redundant prose. However, it could be slightly more concise by removing the repetitive title line, but overall it is well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters with provided choices) and strong annotations, the description is reasonably complete. However, it lacks information about the returned DataFrame's columns or any date/time aspects, and it does not mention how the URL is used. For a simple query tool this is adequate but leaves some ambiguity about the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only parameter names and defaults with zero description coverage. The description compensates by explicitly listing the allowed choices for both symbol ('轿车', 'MPV', 'SUV', '占比') and indicator ('批发', '零售'), which is essential for correct invocation. This is a meaningful addition over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (乘联会 CPCA) and the specific resource (车型大类 vehicle category), and the return type indicates it provides this statistical data. However, it lacks an explicit verb like 'get' or 'query' and does not differentiate this tool from sibling car market tools (e.g., car_market_segment_cpca), earning a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this tool is for vehicle category statistics while other sibling tools handle country, fuel, segment, etc. No exclusions or alternative suggestions are provided, so the agent must infer usage from the name alone.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds the source URL and return type (pandas.DataFrame) but does not disclose data freshness, date range limitations, or response shape. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a clear docstring pattern with params and return type. It is front-loaded with the purpose but repeats '统计数据-厂商排名' in both the title line and return line, adding slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only says the return is a DataFrame, lacking column details, possible time ranges, or how the data is structured. It is sufficient to invoke the tool but insufficient to fully interpret results or select between closely related car_market siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists allowed choices for both symbol and indicator, compensating for the absence of schema descriptions. It also provides types and defaults. However, it does not explain the meaning of values like '单月' vs '累计' or '批发' vs '零售' in terms of resulting data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as CPCA manufacturer rankings via a URL and the name suggests ranking data. It distinguishes from sibling car_market_* tools by specifying '厂商排名' (manufacturer ranking). However, it lacks an explicit verb like '获取' or '返回', making the action implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 car_market_total_cpca or car_sale_rank_gasgoo. The description is purely declarative and does not state use cases, prerequisites, 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the source URL and that it returns a pandas DataFrame, but does not disclose data freshness, schema, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—three short lines—but includes a long URL and docstring-style tags, making it slightly less polished. Nonetheless, it is under 200 characters and front-loads the resource name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is mostly sufficient for invocation, but it fails to describe the content of the Bitcoin position report or any notes on output columns. The simplicity warrants a middle score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameters. The empty schema is fully covered, and the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a Jin10 Bitcoin position report, provides the source URL, and states the return type via ':return: 比特币持仓报告'. This clearly indicates it retrieves a Bitcoin holdings report, distinguishing it from sibling crypto_bitcoin_cme which focuses on CME 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided—there is no mention of when to use this tool over alternatives, no exclusions, and no scenarios described. The description only states what it returns.
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?
Annotations already declare readOnlyHint and non-destructive. The description adds the return type (pandas.DataFrame) and a source URL, providing some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but includes essential info: title, source URL, return type. The docstring format is slightly awkward but each line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool appears simple with no parameters and clear annotations, but the description doesn't specify the DataFrame columns or whether it's historical/current data. For a data fetching tool, users may need more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers what's needed. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (RMB exchange rate central parity) and source (SAFE website), and specifies the return type. It's distinct from sibling currency tools by naming the specific SAFE central parity dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 like currency_boc_sina or forex_spot_em. There is no mention of context or exclusions.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that an API key is required, the return type is pandas.DataFrame, and data is 'latest' (not historical). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a standard docstring with param and return sections, which is structured but includes redundancy (first line repeats the annotation title) and a dangling 'here' link without an actual URL. It is not overly long, but some sentences add limited value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameters, and the annotations confirm it's a safe read operation. However, it lacks output schema details, does not explain possible currency codes or symbols format, and doesn't address errors, rate limits, or when to prefer sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description carries the burden. It explains base and api_key well, but 'symbols' is described as 'a list' while the schema type is string, leaving the format ambiguous. No examples or default values are provided despite defaults existing in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Latest data from currencyscoop.com' and parameter docs clarify it retrieves exchange rates for a base currency with optional symbols. This is clear about the resource and scope, though it lacks an explicit verb and does not distinguish from sibling currency tools like currency_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 currency_history or currency_time_series. It also doesn't explicitly state prerequisites like API key requirement or appropriate use cases.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), but does not elaborate on data content, rate limits, or other behavioral aspects. This adds some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only essential information: title, source URL, parameter documentation, and return type. Although the structure is docstring-style and mixes Chinese/English, it is appropriately sized and every line contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter, read-only tool, the description is adequate but incomplete. It states the return type is a pandas.DataFrame but does not describe what columns or metrics are included in the returned '市场信息'. With no output schema, the description should provide more detail about the return value's structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a default value with no description (0% coverage). The description compensates by listing the allowed enum values ('湖北', '上海', '北京', etc.) and specifying the type as str, which gives agents the necessary parameter semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves market information ('行情信息') from a specific carbon trading website (tanjiaoyi.com). It identifies the resource and action, but it does not explicitly differentiate from sibling tools like energy_carbon_bj or energy_carbon_gz, which serve similar regional purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its alternatives. The description merely documents the parameter and return type, with no mention of use cases, exclusions, or when region-specific siblings might be preferable.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description adds only the source URL and return type. It does not disclose additional behavioral traits such as rate limits, network requirements, or data update frequency beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes the essential URL and return type, but its first line is a verbatim repeat of the annotation title, which is redundant. Despite that, it is concise and front-loaded with the tool's identity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does explain the return type and high-level content (daily overview of quota spot data). However, it lacks specifics such as column names, date range, or data granularity, which would be useful for an agent to interpret the result fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so the schema already fully covers this aspect. The description does not mention parameters, but with no parameters to document, the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns spot trading data for Hubei Carbon Emissions Trading Center (quotas, daily overview) as a pandas DataFrame, and provides a source URL. It distinguishes itself from regional siblings by specifying '湖北' (Hubei), though it lacks an explicit action verb like 'fetch' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like energy_carbon_bj, energy_carbon_gz, or energy_carbon_sz. The description only describes what the tool outputs, not the selection context or any prerequisites.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the source URL and a hint that symbol can be obtained via fund_name_em(). However, it does not disclose pagination, data range, or the structure of the returned DataFrame, which are useful behavioral traits 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a title, URL, parameter doc, and return type. It is not overly verbose and the information is reasonably front-loaded. However, the URL and title are partially redundant with the annotation title, and the description could be more concise by removing the URL or integrating it into a sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description gives the return type (pandas.DataFrame) and the source URL, but it does not describe the DataFrame's columns or the scope (e.g., all historical announcements vs. recent ones). The description is adequate for basic invocation but lacks detail about the data contents, which limits completeness compared to what an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the symbol parameter (0% coverage), but the description explains that symbol is a fund code and recommends using fund_name_em() to obtain valid codes. This adds meaningful semantic context beyond the schema, effectively compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '人事调整' (personnel adjustments) under fund announcements and specifies the return as '人事调整-公告列表' (personnel adjustment announcement list). This makes clear that the tool retrieves fund personnel change announcements. It distinguishes from siblings like fund_announcement_dividend_em by the specific '人事调整' keyword, though it lacks an explicit action verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools such as fund_announcement_dividend_em or fund_announcement_report_em, nor does it state any exclusions or preferred contexts. The only clue is the title, which implies the announcement type, but there is no explicit usage instruction.
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 already declare read-only, idempotent, and non-destructive behavior. The description adds the source URL and return type (pandas DataFrame), which is some context, but doesn't disclose any additional behavioral traits or caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, contains only essential information (purpose, URL, return type), and is front-loaded with the tool's function. It lacks a structured explanation but earns a good score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema), the description provides the essential return type and source. However, it doesn't explain what columns the DataFrame contains or the ranking criteria, which could leave an agent uncertain about whether this matches a need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this. Per the scoring guide, the baseline for zero parameters is 4. The description doesn't need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a fund company ranking list from Eastmoney, with a specific source URL. It doesn't explicitly differentiate from siblings, but the name 'fund_aum_em' and description provide a clear resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any context about the data (e.g., time range, ranking criteria). It simply states the source and return type.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose rate limits, error handling, or the exact DataFrame structure. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-organized docstring with title, URL, parameters, and return information separated clearly. It is not overly verbose and front-loads the data source. The structure is conventional, though the URL line adds moderate value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential information: source, parameters, and return type. However, it lacks details on the returned columns, date range behavior, and usage guidance relative to siblings. In the absence of an output schema, the description should have clarified the return structure more fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by explaining all parameters: symbol (ETF code), start_date, end_date, period choices, and adjust choices. However, date format and period units (minutes) are not explicitly stated, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description title '东方财富-ETF 行情' and return statement '每日分时行情' clearly indicate that the tool fetches minute-level ETF quotes from Eastmoney. The parameter list specifies symbol, dates, period, and adjust. However, it lacks an explicit verb like '获取' and does not differentiate from sibling tools that also provide ETF history (e.g., fund_etf_hist_em), relying on the name 'hist_min' for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any prerequisites, exclusions, or related tools. The URL example is not a usage guide. Given many siblings like fund_etf_hist_em and fund_lof_hist_min_em, this absence of usage context is a clear gap.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type but does not disclose additional behavioral aspects such as data update frequency, data size, or any potential network dependencies. This is acceptable given the annotations, but the description could enrich the 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, URL, and return type lines. It is front-loaded with the most important information and contains no filler. However, it reads as a fragment rather than a well-structured sentence, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description should clarify what the returned DataFrame contains (e.g., columns, scope, whether it covers all funds or specific funds). It only states '持有人结构' without detailing the data shape, leaving the agent uncertain about the exact output. The description is adequate for a simple read-only tool but misses these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The baseline for 0 params is 4, and the description appropriately focuses on the output rather than inputs. No parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing fund holder structure data from Eastmoney, with the specific resource '规模份额-持有人结构' and a return type of pandas.DataFrame. Though it lacks an explicit verb (e.g., 'retrieves'), the name and description together make the purpose 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/5Does 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 the many sibling fund tools. There are no exclusions, prerequisites, or alternative tool references, leaving the agent without context for tool selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the data source endpoint and return type but doesn't disclose additional behavioral details like rate limits or error behavior; the bar for extra context is low but 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is compact and well-structured, including title, URL, params, and return type. The example URL is a minor extra but informative. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description provides a basic idea of the return type (DataFrame) and key parameters, but it doesn't specify what fields the fund information contains or offer any usage context. This leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's parameter docs are essential. It explains symbol as fund code and timeout as None or a positive float, adding meaning beyond the schema. However, the purpose of timeout is not elaborated (e.g., HTTP timeout), so it's not fully complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides 雪球基金-基金详情 (Snowball Fund details) and returns a pandas DataFrame, indicating it fetches basic fund information for a given fund code. However, it doesn't explicitly contrast with sibling tools like fund_individual_detail_info_xq, so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other fund-related tools. The description only provides a data source URL and parameter documentation, with no mention of alternatives or conditions for use.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds that it returns a pandas.DataFrame and includes a source URL, but discloses no additional behavioral details like data freshness, rate limits, or the exact content of the returned 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring-style entry with the title, a source URL, and parameter/return definitions. It is front-loaded and has no redundant filler. It lacks a natural-language sentence, but remains efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with strong annotations, the description is mostly adequate. However, it does not describe the contents of '基金基本信息', nor any limitations on applicable fund types. Given the very large sibling set with many fund_info tools, additional context on selection and expected output columns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'symbol'. The description compensates by explicitly documenting it as '基金代码' (fund code) with type str, which is essential. However, it does not elaborate on format requirements or valid value ranges beyond the default example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '基金基本信息' (fund basic info) from THS (10jqka), with a sample URL and param/return definitions. It is specific enough to distinguish from similar fund_info_* tools by source provider. However, it lacks an explicit action verb like 'retrieve' or 'get', relying on a noun phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many other fund data tools in the sibling set. There are no mentioned alternatives, prerequisites, or exclusions, leaving the agent without decision support.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds that the return type is a pandas.DataFrame and includes a source URL, but it does not disclose data freshness, columns, or any limitations. This is acceptable given the annotations, but not rich in behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a category path, a source URL, and a return type annotation. No fluff is present, and it is appropriately sized for a zero-parameter read-only tool. The structure is a bit ad-hoc but clear enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a zero-parameter read-only tool, the description provides basic essentials: resource, source URL, and return type. However, it lacks details about the returned DataFrame's fields or any filtering options. With no output schema and no usage guidance, the agent may not know what columns to expect or how the data is scoped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). The description does not need to explain parameters. Baseline for 0 params is 4, and the description correctly omits irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '新成立基金' (newly established funds) and provides a source URL (East Money), which distinguishes it from similar tools like fund_new_found_ths. However, it lacks an explicit verb like 'get' or 'list', relying on the tool name and the category path to imply retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 fund_new_found_ths or any other similar tool, nor does it specify the intended use case or context. This is a clear gap for an AI agent selecting between fund data 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?
The description adds little beyond the annotations: it provides the source URL and return type (pandas.DataFrame) but does not disclose data freshness, typical row counts, pagination behavior, or any caveats. With readOnlyHint and idempotentHint already declared, the added behavioral context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a clean docstring structure: title, URL, param, return. It is appropriately sized, though the URL could be considered extra; overall it is well-organized and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description provides the necessary basics. However, the return value is only vaguely described as 'new fund data' without column details or example output, and no output schema exists to fill the gap. It is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates by explaining the single parameter 'symbol' with its meaning ('选择基金类型') and explicit choices ({"全部", "发行中", "将发行"}). This is sufficient for the agent to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for new fund data from THS ('新发基金'), backed by the title and URL. It is clear what it does, but it does not explicitly distinguish itself from sibling fund_new_found_em, which serves a similar purpose from a different data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description mentions the symbol choices but does not compare with other fund tools or state any exclusions. The usage 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds the return type (pandas.DataFrame) and a source URL, but does not disclose additional behavioral traits like pagination, data latency, or any side effects. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a docstring structure with a title, URL, parameter, and return type. Every line serves a purpose, though the URL is arguably redundant. It is front-loaded with the main purpose and avoids excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and strong annotations, the description provides the essential elements: source, parameter choices, and return type. However, it lacks details about the returned DataFrame's columns or data semantics, and with no output schema, the return description is only high-level. This leaves some gaps but is adequate for a simple read-only ranking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does by listing the exact allowed values for 'symbol' (全部, 股票型, 混合型, 债券型, 指数型, QDII, FOF), which are not present in the schema. This gives meaning beyond the raw type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching open fund rankings from Eastmoney's data center ('东方财富网-数据中心-开放基金排行'), which is a specific resource and action. It distinguishes from siblings by the 'open fund' qualifier in both the name and description, though it lacks an explicit verb like 'retrieve' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other fund ranking tools (e.g., fund_exchange_rank_em, fund_hk_rank_em). It only lists the allowed symbol choices, which is parameter guidance rather than tool-selection guidance. No exclusions or alternatives 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?
Annotations already declare read-only and non-destructive behavior. The description adds the return type (pandas.DataFrame) and source URL, which is useful, but does not disclose other behavioral traits such as data granularity, update frequency, or whether any authentication is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core title front-loaded. The embedded URL and docstring add some value but could be better structured. It does not suffer from verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the burden of explaining what the returned data contains. It only states 'fund asset allocation' and the DataFrame type, leaving the exact columns, time period, and scope ambiguous. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the tool takes zero parameters, parameter semantics is inherently satisfied. The description adds context by specifying the return type as pandas.DataFrame, which is helpful even though no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (CNINFO Data Center) and the specific report (fund asset allocation), distinguishing it from sibling tools like fund_report_industry_allocation_cninfo and fund_report_stock_cninfo. However, it lacks an explicit action verb, functioning more as a title than a statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or relationships to other fund report 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the date format constraint and return type (DataFrame), which are useful behavioral details. However, it does not disclose any limitations, pagination behavior, or data scope beyond the generic label '基金重仓股'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, source URL, parameter definition, and return type. It is front-loaded and each section contributes value, but the title line duplicates the annotation title, resulting in minor redundancy overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description covers the source, category, date format, and return type. However, it does not describe the contents or columns of the returned DataFrame, nor any operational limitations. Since there is no output schema, more detail about the return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter without a description (0% coverage), but the description provides the meaning and allowed values: date must be a quarter-end date in the form XXXX0331, XXXX0630, XXXX0930, or XXXX1231. This fully compensates for the schema's lack of semantic detail, though it could be more explicit about the year/month/day interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing fund heavy holdings (基金重仓股) from CNINFO thematic statistics, distinguishing it from sibling tools like fund_report_asset_allocation_cninfo. It includes a resource path and return type, making the main function evident. However, it lacks an explicit verb like 'get' or 'list', relying on the docstring convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative fund-report tools. It only states the date parameter format but does not mention exclusions, prerequisites, or scenarios suited for this tool. The agent is left without criteria for tool selection among many similar fund-related 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds a return type (pandas.DataFrame) and a source URL, but it does not disclose data freshness, column structure, pagination, or any edge-case behavior. This is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the title, a source URL, and return type in three short components. Every element earns its place, and there is no redundancy. It could be more structured with a sentence describing the data, but for a zero-parameter tool, the brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with good annotations, the description is minimally sufficient. It tells the user it returns a pandas DataFrame of closed-end fund scale from Sina, but it does not explain what columns are included, whether the data is historical or current, or how it might differ from similar tools. This leaves some gaps but is acceptable for such a simple endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema coverage is 100% (vacuously), and there is nothing for the description to add. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Sina Finance closed-end fund scale data ('新浪财经-基金数据中心-基金规模-封闭式基金'), distinguishing it from open-end and structured fund scale siblings via the '封闭式基金' qualifier. However, it lacks an explicit verb like 'get' or 'retrieve', functioning more as a title than a declarative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related tools such as fund_scale_open_sina or fund_scale_structured_sina, nor any contextual hints about selecting this specific closed-end fund scale endpoint. The description only states the category without exclusions or 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety expectations. The description adds that the return is a pandas.DataFrame containing 基金规模, which is useful context, but it does not describe pagination, latency, or any potential side effects beyond what annotations imply. No 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a clear structure: a title line, a source URL, and docstring-style parameter/return documentation. Each line serves a purpose, and it avoids unnecessary fluff. The URL adds context but is not essential, yet the overall conciseness is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, no output schema, and annotations present), the description is minimally adequate. It identifies the data source, parameter options, and return type, but does not describe the DataFrame's columns, index, or any filtering behavior. For a straightforward fund-scale lookup, this is sufficient but lacks depth for more nuanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'symbol' parameter (0% coverage), but the description compensates by listing the exact allowed values: {"股票型基金", "混合型基金", "债券型基金", "货币型基金", "QDII基金"} and stating the type is str. This is essential information not present in the schema, though it does not explain the default behavior beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 基金规模 (fund scale) for 开放式基金 (open-end funds) from Sina Finance, with the URL and name distinguishing it from sibling tools like fund_scale_close_sina and fund_scale_structured_sina. The action is implied as fetching/listing data, though not explicitly stated with a verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as fund_scale_close_sina or fund_aum_em. The category '开放式基金' is implied by the title and URL, but there is no mention of exclusions or preferred use cases, leaving the agent to infer from the name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame) but does not disclose additional behavioral traits such as data update frequency, columns included, or any rate limits. It provides minimal added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and avoids unnecessary fluff, consisting of a title, source URL, and return type. However, the structure is fragmented with ':return:' and ':rtype:' lines, and there is slight redundancy between the title and the return description. It is appropriately sized but could be more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description should clarify what the returned DataFrame contains. It only states 'stock fund position' without specifying columns, time range, or units. This leaves the user guessing about the data structure, though the source URL allows further investigation. It is minimally complete but lacks useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parameter semantics to explain. Per guidelines, the baseline for zero-parameter tools is 4, and the description correctly omits parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving stock fund position data from Legulegu (乐咕乐股) with a specific source URL, which distinguishes it from sibling fund position tools like fund_balance_position_lg and fund_linghuo_position_lg. However, it lacks an explicit verb like 'get' or 'fetch', relying on the tool name to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this is specifically for stock-type funds, nor does it contrast with other fund position tools. There are no usage criteria, exclusions, or alternative tools suggested.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds the source URL and return type (pandas.DataFrame) but does not disclose other behavioral traits like data frequency, historical depth, or API limitations. It offers some context beyond annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at five lines, each serving a distinct purpose (title, URL, param, return, rtype). It is reasonably structured with docstring conventions, though the simultaneous use of :return and :rtype is slightly redundant. The key information is front-loaded with the title and URL.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description is minimally adequate: it gives allowed parameter values and the return type. However, it does not describe what the returned COMEX inventory data contains (e.g., columns, date range), nor does it differentiate itself from the many other inventory-related tools in the sibling list. It lacks contextual completeness for an agent to make fully informed decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a single `symbol` parameter with no description and no enum, giving 0% schema description coverage. The description compensates by explicitly stating the allowed values: choice of {'黄金', '白银'}, and provides the default value via the schema. This gives the agent enough semantic meaning to select a valid parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing COMEX inventory data from East Money's data center, with a direct URL to the source page. It distinguishes itself from sibling tools by being COMEX-specific, but it lacks an explicit verb like 'retrieves' or 'gets', relying instead on the noun phrase 'COMEX库存数据'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative inventory tools such as futures_inventory_em or futures_inventory_99. It does not mention any conditions, prerequisites, or explicitly state when this tool is preferred, leaving the agent to infer usage from the tool name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that the date parameter is a trading day and that the return is a pandas.DataFrame, which is useful. However, it does not disclose potential network dependencies, rate limits, or exactly what data fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a title line, source URL, and parameter/return documentation. It avoids unnecessary fluff. The first line merely repeats the annotation title, which is slightly redundant, but overall the structure is clean and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool, the description is adequate: it provides the source URL, explains the date parameter, and states the return type. However, it does not describe what '交易参数' (trading parameters) includes, nor does it list any output columns. Since there is no output schema, this additional detail would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It clearly states ':param date: 查询日期; 交易日' (query date; trading day), which explains the semantic meaning of the parameter beyond the schema's type and default. However, it does not specify the exact date format (though the default '20241129' implies YYYYMMDD).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a '交易参数汇总查询' (trading parameter summary query) for the Shanghai International Energy Exchange, which clearly identifies the tool's function. The resource (INE futures trading parameters) is specific, though the verb is implied rather than explicit. It does not explicitly distinguish from sibling tools like futures_contract_info_shfe, relying on the tool name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description does not mention exclusions or alternative tools for other exchanges, leaving the agent to infer usage from the tool name and the China INE context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL, the fact that the date is a trading day, and the return type (pandas.DataFrame), but does not disclose potential caveats like data availability, invalid date handling, or timezone considerations. It adds some value beyond annotations but not extensive 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured with a source URL, parameter documentation, and return type. It is not verbose, but the first line repeats the title annotation and the return line repeats '交易参数汇总查询' without elaboration. Overall, it is efficient and each section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify the return data. It only states that the result is a pandas.DataFrame containing a 'trading parameters summary query,' which is vague—no columns, contract scope, or data coverage are described. The annotations provide safety context, but the description lacks sufficient detail for the agent to fully interpret the result. It is minimally adequate for a simple date-parameterized query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter and 0% schema description coverage, the description compensates by explicitly documenting the 'date' parameter as '查询日期; 交易日' and specifying its type. It adds meaning beyond the schema, and the default value suggests the expected format. However, it does not explicitly state the YYYYMMDD format or whether the date must be a past trading day, so it is not fully exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'Trading Parameters Summary Query' for the Shanghai Futures Exchange with a specific source URL. The name and description clearly scope it to SHFE, differentiating it from sibling tools like futures_contract_info_cffex. However, there is no explicit verb like 'retrieve' or 'fetch', and the first line largely duplicates the title annotation, so it falls short of a perfect purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mentions a date parameter and return type, and does not reference sibling tools or exclusions (e.g., 'use for SHFE contract parameters, not for other exchanges'). The absence of any usage context leaves the agent without direction for tool selection.
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 already declare readOnlyHint=true and destructiveHint=false, and the description adds only the return type (pandas.DataFrame) and a source URL. It does not add details about data freshness, limitations, or caching behavior, but the annotations lower the bar for safety-related disclosure. The added return-type and scope info provide modest value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, combining a title line, source URL, and structured param/return docstrings. It avoids unnecessary prose, though the URL placement and the mix of Chinese and English make it slightly less elegant than ideal. Still, every line contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data-retrieval tool, the description covers the core inputs and output type, but it lacks detail on the returned DataFrame's columns or how this tool fits with the sibling 'futures_dce_position_rank_other'. Since there is no output schema, more explicit return-structure information would improve completeness. The tool is usable but not fully self-explanatory in a broader tool ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does the heavy lifting by explaining 'date' as a specified trading day with a format example ('20200511') and 'vars_list' as a list of varieties. This meaningfully compensates for the bare schema. It does not enumerate all valid varieties but the default list in the schema supplies that context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (DCE daily position ranking) and the focus on specific contracts, with a return statement indicating it fetches ranking data. It names the exchange and data type, and the title '具体合约' helps distinguish it from the sibling 'futures_dce_position_rank_other'. However, it lacks an explicit verb like 'get' or 'retrieve', so it is slightly below a clear 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 complementary tools, which is a notable gap given the large set of sibling futures and rank-table tools. The usage must be inferred entirely from the name and description.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the data source URL and the return type (pandas.DataFrame), but no additional behavioral context such as data availability, pagination, or error conditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the tool's purpose. The URL and parameter/return documentation are each useful. It is minimally verbose, though the return description is somewhat redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 the description covers the input format and indicates a DataFrame return. However, without an output schema, the description does not explain the actual data content or columns, making it only partially complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It specifies the date parameter format as '年月日' (YYYYMMDD) and type str, and the schema provides a default example. This adds meaningful format guidance beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool queries monthly delivery data from the Zhengzhou Commodity Exchange (CZCE), which is a specific verb+resource. It distinguishes from sibling tools like futures_delivery_dce and futures_delivery_shfe by specifying CZCE, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus other delivery or CZCE-related tools, nor any prerequisites or exclusions. The only hint is the inferred scope from the tool name.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the data source (Sina) and return type (DataFrame), but does not disclose column contents, real-time latency, or any special behavior. This is acceptable for a simple read-only quote tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with title, URL, param, and return lines. It is compact and to the point, with each line serving a purpose. The URL is a minor redundancy but does not detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter realtime quote tool with no output schema, the description covers the data source, parameter acquisition, and return type. However, it does not describe the DataFrame columns or any data specifics, leaving some ambiguity about the result contents. It is minimally complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies symbol as string or array with no description. The description adds that symbol is obtained via a specific subscription function and can be list or str, providing crucial guidance for valid values. This partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '新浪-外盘期货-行情数据' (Sina overseas futures market data) and includes the source URL, making the data source and topic clear. However, it does not explicitly differentiate realtime quotes from sibling tools like futures_foreign_hist or futures_foreign_detail; the generic term '行情数据' weakens the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only explains how to obtain the symbol parameter (via ak.futures_hq_subscribe_exchange_symbol()), but gives no guidance on when to use this tool versus alternatives such as futures_foreign_hist or futures_foreign_detail. The referenced function name may also be inconsistent with the sibling futures_foreign_commodity_subscribe_exchange_symbol, adding potential confusion.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false, establishing a safe read-only profile. The description adds the official data source URL and notes that the date parameter defaults to the current trading day, which is useful context. However, it does not disclose behavioral traits such as rate limits, pagination, or the precise structure of the returned data, so the added value beyond annotations 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. The URL and parameter/return documentation are relevant and directly useful, with no superfluous text. It follows a clean docstring structure that makes the information easy to scan. A slight improvement would be to include a one-line behavior summary, but it is already concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single optional parameter, and annotations cover the safety profile. The description explains the parameter and specifies the return type as a pandas DataFrame, but it does not describe the columns or fields contained in the returned settlement data. Without an output schema, more detail about the data structure would improve completeness, though the low complexity keeps this from being a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies a string 'date' with a default, but the description compensates by explaining the accepted formats (YYYY-MM-DD, YYYYMMDD, datetime.date), the default of 'current trading day', and the parameter type. This is especially valuable given the 0% schema description coverage, as it provides clear guidance on how to specify the date.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing '广州期货交易所-结算参数' (GFEX settlement parameters) and includes a source URL, making it clear that it returns settlement data for the Guangzhou Futures Exchange. The return line confirms data output, and the GFEX reference distinguishes it from sibling exchange-specific tools. However, it lacks an explicit action verb like 'retrieve' or 'fetch', relying instead on a noun phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to choose this tool over alternatives such as futures_settle_ine, futures_settle_cffex, or general futures_settle, nor does it discuss applicable scenarios, prerequisites, or limitations. The only contextual hint is the GFEX name, which implies a specific exchange but is not explicitly stated as a usage criterion.
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 already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds the return type (pandas.DataFrame) and the data's upstream/downstream nature, plus the source URL. It does not disclose further behavioral details like pagination or data freshness, but this is acceptable for a simple read-only fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is compact and well-structured with a title, source URL, and parameter/return documentation. There is no redundant filler, though the URL line is informational rather than strictly necessary for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional parameter and no output schema, the description covers the core purpose, source, and parameter enum. However, it does not describe the structure of the returned DataFrame (columns, row semantics), which could hinder correct use of the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It provides the exact allowed values for 'symbol' (能源, 化工, 塑料, etc.) and its type, which is essential and not available in the schema. It does not explain the meaning of each category, but the values are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (现货与股票上下游对应数据) and source (东方财富网数据中心) clearly, and the sector choices imply a filtering capability. It lacks an explicit verb like 'get' or 'retrieve', but the intent is unambiguous and distinguishable from sibling spot/futures 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/5Does 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 prerequisites, use cases, or exclusions. The sector parameter hints at use for sector-specific spot-stock data, but this is implicit and not stated as guidance.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context: the requirement to copy and pass an acs-token from the target website, the symbol choices (人民币/美元), and the return type (pandas.DataFrame). This goes beyond the annotations and gives the agent practical invocation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a raw docstring with a title, URL, parameter annotations, and return type. It is reasonably concise but not front-loaded with a plain-language summary. The formatting mixes Chinese and English, and some lines (like the URL) are more noise than signal. It is acceptable but not well-structured for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description only partially covers return values by stating 'pandas.DataFrame' but does not describe the columns or the nature of the rankings. It also does not explain how to obtain the acs-token or whether the token is strictly required. Given the tool's simplicity and strong annotations, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters, and the schema description coverage is 0%, so the description must compensate. It does explain 'symbol' as a choice of {'人民币', '美元'} and 'token' as the acs-token copied from the target site. However, the meaning of 'symbol' (e.g., base or quote currency) is ambiguous, and the token requirement is stated but not elaborated. The description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's domain: '百度股市通-外汇-行情榜单' (Baidu Stock Market - Foreign Exchange - Market Rankings) along with a specific URL. The tool name 'fx_quote_baidu' further reinforces that it fetches quotes. However, it lacks an explicit verb and does not differentiate itself from sibling forex tools like forex_spot_em or fx_spot_quote, so it is clear but not perfectly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions or specific scenarios, and the URL is the only hint of its source. Given the large number of similar forex tools among siblings, the absence of usage guidance leaves the agent without context for appropriate selection.
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 already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds useful context by showing the return type (pandas.DataFrame) and a sample of the output columns, but does not disclose details like pagination, rate limits, or potential errors. This is above baseline 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool's purpose and a list of indices, which is good. However, the large sample data table takes significant space and, while informative, makes the description somewhat verbose. It could be condensed without losing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only data retrieval tool with no output schema, the description covers the essential aspects: what data is returned (DataFrame with date, price, volume, etc.), which indices are supported, and parameter meanings. Given the annotations cover safety and idempotency, the description is quite complete, though it could benefit from noting the source URL's default and any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It defines url as '网址' (URL) and name as '中文名称' (Chinese name), and crucially lists all valid name values ('奇货黑链', '奇货商品', etc.), which is essential for correct invocation. The defaults in the schema are also echoed, making parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool obtains QHKC index data and lists the specific indices available. It distinguishes itself from unrelated tools, but does not explicitly differentiate from sibling QHKC tools such as get_qhkc_index_trend or get_qhkc_index_profit_loss, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions or alternative tools for related data (e.g., profit/loss or trend data), leaving the agent to infer usage solely from the tool name and list of indices.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the data range and return type (specific year dataframe), but does not disclose any other behavioral traits such as limits, authentication, or data completeness. Since annotations cover a lot, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the main purpose is front-loaded. It repeats '2012-2018' and uses docstring formatting that could be cleaner, but it remains concise without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is mostly complete: it states the data source, range, and return type. However, it does not describe the dataframe's columns or interval details, nor does it provide any usage context or error handling information, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'year' parameter (0% coverage), but the description compensates by specifying valid values (2012-2018) and the return behavior (dataframe for the specified year). This adds meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as S&P 500 minute data for 2012-2018, which is specific and distinguishes it from the many other stock and index data tools in the sibling list. It lacks an explicit verb like 'get' or 'fetch', but the noun-phrase description is sufficient to understand the tool's 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/5Does 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 only states the data range and parameter details, with no mention of alternative tools for other indices or time periods, nor any context about appropriate use cases.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe read operation. The description adds a source URL and return type (pandas.DataFrame) but does not disclose details like data granularity, update frequency, or column contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three lines) and front-loaded with the resource name and URL, followed by return annotations. It contains no fluff, though the URL may be of marginal value and the structure reads like a docstring rather than prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter read-only tool with no output schema, the description gives a minimal but identifiable purpose via the index name and return type. However, it lacks important context such as the data's time range, scope, or DataFrame columns, leaving gaps that an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the input schema confirms this with 100% coverage. The description augments this by stating the return value and type, which is adequate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the resource ('AI策略指数' from 财新数据) and provides a source URL, making the tool's intent clear. It does not use an explicit verb like 'get' or 'fetch', but the ':return:' annotation confirms it returns the index. It differentiates from sibling index tools by specifying the AI strategy index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the many sibling tools (e.g., index_si_cx or other index_*_cx variants). There is no mention of use cases, 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the source URL and the return type (pandas.DataFrame), but it does not disclose what the returned data actually contains, any potential data freshness issues, or other behavioral details. This is modest added value 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear sections for source URL and parameters. It is well-structured and not overly verbose. The only redundancy is repeating the title as the first line, but that is minor. Overall, it is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with three optional parameters and no output schema. The description defines all parameters and provides the source URL, but the return value is only described as '指数分析', which is vague. Since there is no output schema, the description should better explain what columns or data the DataFrame contains. The tool is not complex, but the missing output detail leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (coverage 0%), so the description must compensate. It provides the allowed values for symbol (市场表征, 一级行业, 二级行业, 风格指数) and explains start_date/end_date as 开始日期/结束日期. This adds meaning beyond the bare schema. However, the date format is not explicitly given (only implied by defaults), so it is slightly incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (指数分析 from 申万宏源研究) and the scope (choice of symbol categories). The return type is stated as pandas.DataFrame. However, the verb (e.g., 'retrieve', 'fetch') is not explicit, and sibling differentiation (daily vs. weekly/monthly) relies on the tool name rather than 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/5Does 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 index_analysis_weekly_sw or index_analysis_monthly_sw. There are no use cases, prerequisites, or exclusions. The docstring only lists parameters without contextual usage direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the return type and specific index name, but does not disclose details like data granularity, time range, or update frequency. It provides some context beyond annotations but is 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a title, URL, return description, and type. It is front-loaded with the resource name and contains no unnecessary prose. The Python docstring markers are slightly technical but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with good annotations, the description is mostly sufficient. It states the output type and source, but the absence of an output schema means the description should clarify what data is returned (e.g., columns, frequency). It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and trivially fully described. The description adds no parameter information, but none is needed. Baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the '基石经济指数' (Cornerstone Economic Index) from Caixin Data, with a source URL and a pandas.DataFrame return type. The resource is specific and distinct from sibling index tools, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other index_*_cx tools or macro indices. The description is purely descriptive and does not mention exclusions or alternative 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds a useful caveat about the unknown data update time (Note: 不知道数据更新时间), which is valuable transparency beyond the annotations. However, it does not describe other behavioral aspects such as network requirements, potential delays, or pagination, leaving the description to carry only a modest amount of extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the title and URL upfront, followed by the return type and a note. It avoids fluff and directly states the core purpose. The URL is a bit long, but it is useful for identifying the source. The structure is clean and front-loaded, though the Chinese text might be slightly less accessible to English-only agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list retrieval tool, the description covers the basics: source, return type, and a caveat. However, it lacks details about the DataFrame contents (e.g., columns, number of rows, index code naming conventions) which would help the agent use the output correctly. Given the absence of an output schema, the description carries the full burden of explaining the return value and falls short of being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is empty and the description needs no parameter explanations. Per the rubric, zero parameters warrant a baseline score of 4, and the description correctly does not invent unnecessary parameter details. The return type is specified, adding clarity about the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the latest index list from the CSIndex website (中证指数网站), including a URL and the return type as a pandas DataFrame. It distinguishes itself from similar index tools by explicitly naming the source (csindex.com.cn) and the scope (all indices). However, the verb 'returns' is only implied in the docstring, not explicitly stated as a primary action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like index_all_cni or stock_zh_index_hist_csindex. It does not mention any prerequisites, exclusions, or specific scenarios. The description is purely functional with no contextual usage hints.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that the return type is a pandas DataFrame and that the symbol can be fetched from another function. It does not reveal behavioral traits like date range coverage, data frequency, or output columns, but given the annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, URL, parameter explanation, and return type. It is appropriately sized and front-loaded with the tool's purpose. Each line has a clear function with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, but the description only states that it returns historical market data as a DataFrame. It lacks details about the data columns, date range, frequency, or any limitations. Since there is no output schema, these missing details make it somewhat incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must compensate. It explains that 'symbol' is the index name and instructs how to obtain it via another API function, plus provides a default value. This adds meaningful guidance beyond the bare schema, though it could enumerate valid symbols or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the tool as providing historical market data for global indices from Eastmoney, with a specific source URL. It identifies the action (retrieve historical quotes) and resource (global index) distinctly. It does not explicitly differentiate from sibling tools like index_global_hist_sina, but the name and URL make the source evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the symbol can be obtained via ak.index_global_spot_em(), which gives a hint on input sourcing. However, it provides no guidance on when to use this tool versus alternatives, nor does it state any exclusions or preferred scenarios. The usage context 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), which gives modest behavioral context beyond the annotations. It does not contradict the annotations and provides no negative side effects, but it does not deeply describe what the DataFrame contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a compact docstring with a title, source URL, parameter definition, and return type. It is mostly efficient, though the return line repeats '中国柯桥纺织指数' after the initial title, which is mildly redundant. Overall, the format is organized and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations, the description covers the essentials: what to pass and the return type. However, it does not describe the structure of the returned DataFrame (e.g., columns, time range, history) nor any query limitations. Given no output schema, this leaves some gap, but for such a straightforward index retrieval tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single symbol parameter with 0% description coverage, so the description's explicit enumeration of valid choices ({'价格指数', '景气指数', '外贸指数'}) is essential and adds significant meaning. It tells the agent exactly what values are accepted, compensating for the schema's lack of detail. However, it does not explain the nuances of each choice beyond their literal names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '中国柯桥纺织指数' and implies retrieval of this index through its parameter and return documentation. It goes beyond a tautology by specifying the index source URL and that it returns a pandas DataFrame, making the tool's function clear even though no explicit verb like 'get' or 'fetch' is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists parameters and return type but does not explain context, exclusions, or relationships to sibling tools such as index_kq_fashion. The only implicit hint is that it serves data for the Keqiao textile index, but there is no explicit 'use this when' language.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the source URL, which are useful but not behavioral traits like rate limits or data granularity. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a title, URL, and docstring, but the title is redundant with the annotations title and the URL adds length. It is not overly verbose, but some content could be trimmed for front-loading the core purpose. Overall, it is acceptably concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter data retrieval tool with strong annotations (read-only, idempotent), the description is adequately complete: it states the data type, parameter meaning, and return type. It lacks minor details like supported symbol ranges or the exact time series resolution (e.g., 1-minute, 5-minute), but these are not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (symbol) with no description (0% coverage), but the description explains ':param symbol: 指数代码' (index code) and specifies the default '801001' via schema. This adds essential meaning missing from the schema, though it does not elaborate on valid code formats or how to discover them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing index minute data ('指数分时数据') sourced from Shenwan Hongyuan Research, and the URL specifies the exact data domain. It distinguishes from siblings like index_hist_sw (daily history) and index_zh_a_hist_min_em (different source) through the 'sw' suffix and source context, but lacks an explicit verb (e.g., 'fetch' or 'get').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as index_hist_sw for daily data or index_zh_a_hist_min_em for another source. It only states what it returns, with no exclusions or scenarios. The usage context is implied solely by the tool name and resource label.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the return type (pandas.DataFrame) and a source URL, which is some useful context, but it does not clarify the temporal scope of the data or update frequency. This is minimal but acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a title, URL, and docstring. It is slightly redundant by repeating the tool name, but overall it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description tells what is returned (QVIX series as a DataFrame) but does not specify whether it returns historical data, a single current value, or a date range. Given the lack of an output schema and the simplicity of the tool, more detail about the data's nature would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the input schema is trivially 100% covered. The baseline for 0-parameter tools is 4, and the description does not need to explain any parameters. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (中证1000股指期权波动率指数 QVIX) and provides a source URL. It unambiguously states what data the tool returns, but lacks an explicit verb like 'get' or 'fetch'—the purpose is implied by the name and the :return: line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling QVIX tools for other indices (e.g., index_option_300index_qvix). There is no mention of prerequisites, exclusions, or alternatives, so an agent receives no help in selecting this 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a pandas.DataFrame return type and a source URL, but does not elaborate on data frequency, coverage, or limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, containing only a title-like phrase, a source URL, and return type information. The first line duplicates the title, but the overall size is appropriate for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description names the resource and return type, which is minimally sufficient. However, it does not state whether this is a daily or spot series (leaving the 'min' sibling to differentiate), nor does it describe historical coverage or data columns, so the agent must infer from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. No parameter documentation is needed since the input schema is empty and the description does not reference parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the 300 ETF option volatility index QVIX, and the name/title reinforce this. It stops short of explicitly contrasting with sibling QVIX tools (like the 'min' variants), but the resource 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/5Does 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 the many similar QVIX siblings (e.g., index_option_300etf_min_qvix, index_option_300index_qvix). There is no mention of use cases, prerequisites, or alternatives.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the data source URL and confirms the return type (pandas.DataFrame), which goes beyond annotations. However, it does not disclose any further behavioral details such as data granularity (e.g., 1-minute vs 5-minute intervals), trading session specifics, or potential network dependencies. It is not misleading but does not enrich the behavioral picture beyond the basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's identity. It includes a helpful source URL and a clear rtype declaration. The main redundancy is the repetition of the same Chinese phrase after ':return:', which could be omitted without loss of information. Overall, it is appropriately sized and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter retrieval tool, and the description states the resource and return type sufficiently for a basic invocation. However, since there is no output schema, the description should ideally clarify the expected DataFrame structure (e.g., column names, index, frequency), but it does not. The source URL helps, but the tool remains underspecified for an agent that needs to interpret the return value programmatically. It is adequate for calling the function but incomplete for data understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, meaning there is nothing to describe. The baseline for 0-parameter tools is 4, and the description adds no parameter-related confusion. It avoids inventing unnecessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: '上证50股指 期权波动率指数 QVIX-分时' (SSE 50 Stock Index Options Volatility Index QVIX intraday). It also specifies the return type as pandas.DataFrame, and the appended URL provides the data source. However, it lacks an explicit verb (e.g., 'fetch', 'get'), and the distinction from sibling tools like index_option_50index_qvix (non-min) relies on the parenthetical '分时' rather than any clarifying wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Despite a large sibling list of QVIX tools for different underlyings and timeframes (e.g., index_option_50index_qvix for daily data, index_option_50etf_min_qvix for ETF-based QVIX), the description does not mention these alternatives or any exclusion criteria. The only hint is the name and '分时', which imply intraday use, but that is implicit and not stated as usage guidance.
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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotence. The description adds the return type (pandas DataFrame) and source URL, but does not disclose additional behavioral traits such as data granularity, historical coverage, or any quirks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes essential metadata (title, URL, return type) without redundancy. It is somewhat fragmented as a docstring fragment, but it is appropriately sized and front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description indicates what data is returned and its type, but does not explain the structure, frequency, historical depth, or columns of the DataFrame. With no output schema, this leaves ambiguity about the actual data content, though for a simple read-only PMI fetcher it may be adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description needs to document no parameters. Since there are no params, the baseline is 4, and the description adds nothing beyond that, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning Caixin China Services PMI data, with the title, URL, and return type specifying the exact series. The name distinguishes it from sibling PMI tools (manufacturing, composite), though the description itself does not explicitly contrast 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/5Does 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 consists only of the title, source URL, and return type, with no mention of use cases, exclusions, or relationships to sibling PMI 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the tool is clearly a safe read operation. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose any further behavioral traits such as data granularity, update frequency, or potential errors. This is adequate for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the tool's purpose. It includes a source URL and a compact param/return docstring. The main drawback is slight redundancy: '中国公路物流运量指数' appears both in the first line and again in the return line, which could be simplified without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 the presence of annotations, the description covers the basics: what is returned, the parameter choices, and the data source. However, it does not describe the structure of the returned DataFrame (e.g., columns or index), nor any coverage or frequency details. This is a notable gap since there is no output schema to provide that information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter description and lacks an enum, so the description compensates by listing the allowed values for 'symbol': 月指数, 季度指数, 年度指数. This is essential information for correct invocation. However, it does not elaborate on what each choice means beyond the labels themselves (monthly, quarterly, annual), which are fairly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the China highway logistics volume index, with a source URL and return type. The name 'index_volume_cflp' and the content distinguish it from the sibling 'index_price_cflp', but the description itself does not explicitly contrast it with that tool. The verb is implied ('return') rather than explicit, but the purpose is still evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description simply lists parameter choices and return type, with no mention of use cases, prerequisites, or exclusions. Sibling tools like index_price_cflp are not referenced, and no context about selecting monthly vs quarterly vs annual is provided beyond the literal labels.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds the source URL and return type (DataFrame), which provides some context about the data source but does not disclose other behavioral traits like data freshness, column details, or pagination behavior. Given the annotations, this is an acceptable but not enriched disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the tool's title and source URL. It includes only essential information, though the return line repeats the indicator name already in the title and the rtype line is redundant for a function that will return a DataFrame. It is still concise and well-structured for a docstring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool, the description provides enough to understand the basic purpose and source, but it omits details like data frequency (quarterly is in the name), historical depth, column names, or units. Since there is no output schema, more detail on the returned DataFrame would improve completeness, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is trivially 100%. With no parameters to document, the baseline is 4, and the description does not need to explain any inputs. The description adds nothing about parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: it returns Australia's Producer Price Index quarterly data from Eastmoney. The Chinese title and return line specify the exact indicator and source, distinguishing it from sibling tools like macro_australia_cpi_quarterly. However, it lacks an explicit action verb such as 'get' or 'retrieve', relying on the function name and return statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other Australia macro indicators. The description is purely declarative, stating what the tool returns but offering no context about when it is appropriate or how it differs from similar tools like macro_australia_cpi_quarterly or macro_australia_retail_rate_monthly.
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 declare the tool as read-only, idempotent, and non-destructive, covering safety. The description adds the data source URL and return type (pandas.DataFrame), but this is minimal. It does not describe potential quirks like date ranges or data granularity, but given the annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, including only the source, the return data concept, and the return type. It is not verbose, though the structure is more of a code docstring than a human-readable explanation, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description is somewhat complete but lacks details about the returned DataFrame contents (columns, frequency, units) and historical coverage. The source URL hints at context but is not explained. For a simple data retrieval tool, this is near the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). No parameter documentation is needed, and the description does not attempt to add unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning Australia's trade balance (贸易帐) from East Money economic data, naming a specific resource and the returned data. It distinguishes from sibling Australia macro tools by the trade balance topic, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling Australia macro tools, the description does not mention that this is specifically for trade balance data or exclude other indicators.
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 already indicate read-only, idempotent, and non-destructive behavior. The description adds the date range and return type but does not disclose additional traits like update frequency, data granularity, or limitations. It does not contradict the annotations, but the added behavioral context 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant repetition of the tool's purpose (title and return line both mention '英国央行决议报告') and two source URLs that are not essential for an AI agent to invoke the tool. It is front-loaded with the main purpose, but some lines could be trimmed for greater conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description effectively communicates the data source, date range, return type, and measurement unit. It lacks details like index format or update frequency, but is largely complete for the tool's simplicity. The absence of an output schema is partially compensated by the explicit return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description correctly focuses on return type (pandas.Series) and value unit (%). With no parameters to document, the baseline of 4 applies, and the provided return information is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the Bank of England decision report with a data range from 1970-01-01 to present, and specifies the return as current value (%). It differentiates from sibling central bank tools by naming '英国央行' (Bank of England). However, it lacks an explicit verb like 'fetch' or 'get', making the action somewhat implied rather than directly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_uk_bank_rate or other central bank interest rate tools. It only states the data range and source, not the recommended context or exclusions. Given the extensive sibling list, this is a notable gap.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect behavior. The description adds a source URL and return type (pandas DataFrame) but does not disclose additional behavioral traits such as data frequency, historical range, or units. This modest addition warrants a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of a title, URL, and return type. While every line is purposeful, it is more of a docstring fragment than a structured description. It is concise and front-loaded with the resource name, but lacks a clear narrative sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only tool, the description provides the source and return type. However, it omits practical details like the time series frequency (e.g., monthly), the historical period covered, or column names. Since there is no output schema, these details would help the agent set expectations. The annotations compensate somewhat, but the description remains minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. According to the rubric, a baseline of 4 is appropriate when there are no parameters. The description does not need to explain parameter semantics, and no information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Eastmoney economic data for Canada's unemployment rate. It also specifies the return type (pandas DataFrame) and provides a source URL. However, it lacks an explicit action verb like 'get' or 'retrieve', relying on the tool name and context, which slightly weakens clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or distinguish it from other macro economic data tools for Canada or other countries. An agent is left without context on selection.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the data range and source URL, but does not elaborate on the DataFrame structure, potential latency, or any operational caveats. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core meaning. The URL and return type are additional but not wasteful; however, they are somewhat disconnected as a single sentence. Overall, it is concise with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not specify the content or columns of the returned DataFrame, which is a notable gap for a report-style tool. It gives enough to start using the tool but not enough to fully anticipate the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, making coverage vacuously complete. The description's data-range note adds useful context about what historical data is available, which is a baseline 4 for parameter-free tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the Shanghai Gold Exchange report and its data range from 20100331 to present, making the tool's purpose understandable. However, it lacks an explicit verb like 'fetch' or 'retrieve' and does not explicitly contrast with other SGE-related 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/5Does 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 other macro or SGE report tools. It is purely descriptive and does not mention any prerequisites, exclusions, or preferred contexts.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a source URL and return type (pandas.DataFrame) but does not disclose additional behavioral traits such as data frequency or filtering limitations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the data name. It repeats the Chinese phrase twice and includes a URL and return type, but every sentence serves a purpose. It could be more concise by removing duplication, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description is adequate: it states the indicator and return type. However, it does not specify the data's time range, frequency, or any additional columns beyond the count, leaving some ambiguity about what the DataFrame contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to explain. The description's mention of the return type adds minimal value but is not necessary; baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the data being returned: the number of bank wealth management products issued (银行理财产品发行数量), and provides a source URL. It distinguishes this from sibling macro tools by specifying a unique indicator, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternative macro indicators, nor does it mention any exclusions or prerequisites. It merely states what data is returned without context for selection.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing a clear safety profile. The description adds the return type (pandas.DataFrame) and source URL, which is useful but does not elaborate on data granularity, update frequency, or potential network dependencies. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat repetitive: the title, URL, and return line all convey the same dataset. It is not poorly structured, but it lacks a clear separation of purpose, source, and output. The URL might be superfluous for an agent, though it is not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless data retrieval tool with strong annotations, the description provides sufficient context: the dataset name, source URL, and return type. It does not specify data columns or time coverage, but given the low complexity and no output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). The description correctly omits parameter details, and with no parameters to explain, a baseline of 4 is appropriate. It adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the central bank monetary authority balance sheet from Sina Finance's China macroeconomic data section. It names the specific dataset and provides a source URL, distinguishing it from other macro_china_* tools. However, it lacks a direct verb like 'get' or 'fetch', relying on the implicit return statement to convey its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 preferred use cases. It is purely descriptive and does not help an agent decide between this and sibling tools like macro_china_money_supply or macro_china_pmi.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is established. The description adds the source URL and return type (pandas.DataFrame), which is useful context, but it does not disclose data update frequency, date range, or any quirks. Given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact: three lines containing the title, a source URL, and return type. It is appropriately concise for a no-parameter retrieval tool, with no wasted words. It reads like a stub rather than a polished description, but the brevity is suitable for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description gives the essential 'what' (construction materials price index) and 'where' (East Money URL), but it does not describe the returned DataFrame columns (e.g., date, value). Since there is no output schema, the description carries the burden of explaining return values, and it falls short of being fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% (trivially). There is nothing for the description to explain regarding parameter meaning, and the baseline for 0 parameters is 4. The description correctly does not attempt to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource as '建材价格指数' (construction materials price index) and indicates a pandas DataFrame return type, which clearly identifies what the tool provides. It avoids being a pure tautology by adding the data source URL and the return type, but it lacks an explicit verb like 'get' or 'retrieve' and does not explicitly distinguish itself from the closely named sibling macro_china_construction_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many other macro_china_* index tools (e.g., macro_china_construction_index, macro_china_commodity_price_index). There is no mention of alternatives, prerequisites, or suitable scenarios, leaving the agent without context for selection.
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?
The description adds useful behavioral context beyond annotations: the date range, a source URL, and the pandas.DataFrame return type. However, it does not disclose specifics like whether the data represents year-over-year percentage change, column names, or update frequency, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the key information (annual CPI and date range). The URL and :return/:rtype docstring lines are useful but slightly redundant with the title and name, yet the overall structure is clean and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0 parameters, good safety annotations, and no output schema, the description covers the basics: what data (annual CPI), the time span, and the return type. However, it omits important context such as the exact units (year-over-year percentage), column names, or the fact that it is historical annual data, leaving the agent uncertain about the data's semantic meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% with an empty schema. The baseline for 0-parameter tools is 4, and the description does not need to explain parameter semantics, though it does mention the date range as a property of the data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing China annual CPI data with a specific date range (19860201 to present), which distinguishes it from monthly or other CPI-related siblings. However, it lacks an explicit verb like 'retrieve' or 'list,' relying on the noun phrase '中国年度 CPI 数据' to imply action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_china_cpi_monthly or other CPI tools. It does not mention exclusions, prerequisites, or contextual cues for selection, leaving the agent without decision-support information.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the key safety aspects. The description adds the date range, source URL, and return type, which is useful context, but it does not disclose potential quirks like column names, units, or any processing limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the essential info: data subject, date range, source URL, and return type. It is somewhat unstructured as a single string, but it avoids unnecessary detail and is appropriately sized for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and empty schema, the description provides the core details: what data, from when, from where, and the return type. However, it does not specify the columns or structure of the DataFrame, which would be helpful for a data tool. Without an output schema, this gap is noticeable but not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the schema fully covers parameter semantics. The description adds context about the data being returned but does not need to explain parameters that don't exist. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Chinese daily coastal six major power plant coal inventory data with a specific date range and source URL. Although it lacks an explicit action verb like 'get' or 'retrieve', the ':return: pandas.DataFrame' indicates the output type, making the purpose specific and distinguishable from sibling 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/5Does 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 macro_china_energy_index or other macro data tools. The description only states what data is returned, not under what circumstances 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the source URL, but these are minor additions. It does not disclose other behavioral traits like the data range, granularity, or any potential quirks, but given the annotations, the lack of such detail is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and to the point, consisting of a source name, URL, and return type annotations. It does not waste words, though the docstring-style ':return:' and ':rtype:' are a bit awkward. Still, it is appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the tool returns '外商直接投资数据' (FDI data) as a pandas DataFrame, but it does not specify the data's structure, time coverage, or units. This might be acceptable for a zero-parameter tool that returns all available data, but without an output schema, more context would help an agent understand what the returned DataFrame contains. Still, the name and source URL provide reasonable context for a macro data lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not responsible for explaining parameter semantics. The baseline for 0 params is 4, and the description does not need to add anything beyond what the schema already shows (empty object). It correctly implies a no-argument data retrieval operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning China's foreign direct investment data from East Money ('东方财富-经济数据一览-中国-外商直接投资数据'), and the name macro_china_fdi matches. It lacks an explicit verb like 'fetch' or 'get', but the resource and scope are unambiguous. It does not explicitly differentiate from sibling macro tools, but the specific FDI indicator is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. While the name implies it is for China FDI data, there is no explicit context such as 'Use this when you need...' or any mention of how it differs from other macro_china_* siblings. The usage context is only implied by the resource name, which is weak guidance.
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 already indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that data spans from 20110120 to present and that it returns a pandas DataFrame, which is useful. However, it does not disclose other behavioral traits like update frequency, pagination, or potential errors, but with annotations present, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, containing a title, URL, return type, and a note about the return format. The structure is clear but includes a redundant '金十数据中心-中国 GDP 年率报告' repeated from the title and a standard docstring format. No wasted sentences, but it could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description covers the return type and data range. However, it does not explain the columns of the DataFrame, the meaning of '年率' beyond the name, or how this tool differs from macro_china_gdp. Given the large number of sibling tools and lack of output schema, a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage (100%). The description reinforces that no parameters are needed by simply stating the data range and return type. With 0 params, baseline is 4, and the description adds reasonable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: China GDP year-on-year rate report from Jin10 Data Center, with a specific data range. However, it lacks an explicit verb like 'fetch' or 'retrieve', relying on the name and context. It distinguishes from siblings like macro_china_gdp by specifying '年率' and the data range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_china_gdp or other GDP-related tools. There is no mention of preferred use cases, exclusions, or comparisons. The description merely states what it is and provides a URL.
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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the source URL and return type (pandas.DataFrame), which is helpful but does not disclose additional behavioral details such as data granularity, update frequency, or potential network dependency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title line, a URL, and a return type. It is easy to scan and contains no unnecessary filler. However, the title is redundant with the description, and the lack of any usage context slightly reduces its structural polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, the description provides core information: what data it returns and from where. However, it does not specify the format or columns of the DataFrame, the time range covered, or how the data is organized. The annotations cover the read-only nature, but the description only minimally fills in the data semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need for parameter explanations. The baseline for zero-parameter tools is 4, and the description does not need to compensate for any missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing industrial value-added growth (工业增加值增长) from Eastmoney's economic data section, with a source URL. It clearly distinguishes itself from sibling macro_china_* tools by naming the specific indicator. However, it lacks an explicit action verb like 'fetch' or 'retrieve', relying on the return type to imply the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many other macro_china_* siblings. The description only lists the source URL and return type without any context about typical use cases, data frequency, or when an alternative 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the source URL and return type but provides no additional behavioral context such as data structure, time range, or limitations, which is acceptable given the simple read-only nature but adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with labels, front-loading the key resource information. It repeats the Chinese title in the :return: field, which is slightly redundant, but overall it is minimal and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool, the description covers the source and return type. However, it lacks details about the DataFrame columns, data period, or any qualifiers, which would help an agent understand the exact output and how to interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so parameter semantics are trivially satisfied. The description does not need to compensate for missing parameter details, meeting the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the Eastmoney customs import/export increase/decrease list and provides the source URL and return type (pandas.DataFrame). While it lacks an explicit verb like 'fetch', the meaning is unambiguous and the tool is distinguished from other macro_china_* siblings by its specific data content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It only states the data source and return type, with no mention of exclusions or alternative tools, leaving the agent to infer usage solely from the resource description.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the return type is pandas.DataFrame and the data comes from East Money, but it does not disclose additional behavioral traits such as data frequency, historical depth, or potential delays, which would be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the title, source URL, and return type in a few lines. It is appropriately sized for a no-parameter tool, though the inline URL adds minor clutter. The essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description tells the user what is returned but misses helpful context such as the data's time coverage, units, or whether it is monthly/annual. The annotations and simple nature of the tool lower the burden, but the description could still be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 semantics, and the empty schema is fully documented. No omissions are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 香港楼宇买卖合约数量 (Hong Kong building sale/purchase contract volume) as a pandas DataFrame, with a source URL. It is specific about the resource but does not explicitly distinguish itself from the similar sibling macro_china_hk_building_amount, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like macro_china_hk_building_amount or other macro China-HK indicators. The description only states the data source and return type, with no context on expected use cases or criteria for selection.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds useful context about the data range and return type (pandas DataFrame with current values in percent) but does not disclose other behavioral aspects such as update frequency or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes raw URLs and docstring-style return information, making it slightly cluttered. It front-loads the report name, but the structure is not as clean as it could be. Still, every sentence adds some value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool, the description covers the key aspects: what data is returned, the period, the return structure, and source links. It lacks details on update frequency or caveats, but given the simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and fully covered. The description's mention of the data range is informational, not a parameter. The return type and value are described, which compensates for the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the Hong Kong interbank lending report (香港同业拆借报告) with a specific data range (20170320 to present), and explicitly states the return value is the current value in percent. This distinguishes it from sibling macro tools, though it lacks an explicit verb like 'retrieve' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the data source and range, with no mention of use cases, exclusions, or sibling 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the return type (pandas.DataFrame) and source URL but no additional behavioral context like update frequency or data limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three lines including the title, URL, and return type. There is no redundant verbiage, though the title is repeated from the annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, parameterless economic indicator tool, the description provides the essential information: source, indicator name, and return type. However, it omits details like time range or update schedule, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema has no properties. The description does not need to explain parameters since there are none, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data resource as '香港商品贸易差额年率' (Hong Kong merchandise trade balance annual rate) from East Money, with a source URL. It clearly indicates the tool returns this economic indicator as a pandas DataFrame, distinguishing it from other macro_hk_* tools by specifying the exact 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/5Does 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 conditions, prerequisites, or comparisons to sibling 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?
The annotations already declare this as read-only, idempotent, and non-destructive, so the description has a lower burden. It adds a source URL and states the return type (pandas.DataFrame), but provides no additional behavioral context such as data coverage, frequency, or update schedule.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes a useful source URL. However, it repeats the term '原保险保费收入' three times (in title, description, and docstring), which is slightly redundant but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter macro data tool, the description gives the source URL and return type, which is a reasonable starting point. However, it does not specify the DataFrame's columns, time range, units, or whether it is historical or current, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is fully covered. With no parameters to document, the description is not expected to add parameter details, and any additional info would be optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: China original insurance premium income, and provides a source URL. While it lacks an explicit verb like 'fetch' or 'list', the intent is unambiguous. It does not explicitly differentiate itself from the sibling macro_china_insurance, but its specificity is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention context, exclusions, or comparisons with sibling macro tools, leaving the agent to infer usage from the name alone.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that it returns a pandas.DataFrame, which is useful but minimal. It does not disclose data range, columns, or error behavior, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, consisting of a title, a URL, and return type annotations. It is concise and front-loaded, though the structure is slightly fragmented with separate :return: and :rtype: lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides the data source and return type, but lacks detail on the structure or content of the returned DataFrame. Since there is no output schema, more explanation about the data (e.g., columns, time range) would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivial. The description correctly implies no arguments are needed, and the schema confirms this. The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific dataset: 新浪财经-中国宏观经济数据-国际旅游外汇收入构成, and includes a source URL and return type. It distinguishes from sibling tools by naming the exact resource, but lacks an explicit verb like 'retrieve' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other macro data tools. The description only states the source and return type, with no mention of use cases, 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint values, so the safety profile is covered. The description adds a fixed data range and source URL, which is useful context. However, it does not elaborate on data nuances, such as whether values are seasonally adjusted or what columns the DataFrame contains, but given annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but contains redundancy, with the return type and data description each stated twice (in prose and in :return: fields). It is front-loaded with the main purpose and remains short, so it does not waste much space, but it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides the return type (pandas.DataFrame) and the data range, which is the minimum needed. For a simple retrieval tool it is adequate, but it does not specify the DataFrame's columns or structure, leaving the agent to infer that information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so parameter semantics are not a burden. Baseline for 0 params is 4. The description adds that the data range is fixed from 19980201 to present, providing useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing China's annual M2 data, specifies the date range, and includes a source URL. It distinguishes from siblings like macro_china_money_supply by explicitly stating 'M2' and 'yearly'. However, it lacks an explicit verb such as 'retrieve' or 'get', so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related tools or scenarios where this would be preferred, despite the sibling list containing similar macro money supply tools. The only context given is the data range and return type.
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 already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and indicates the return type, which provides some context beyond annotations. However, it does not disclose behavioral traits such as data freshness, time coverage, or any filtering/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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact, consisting of a one-line title, a source URL, and two short docstring lines specifying return value and type. Every element adds useful information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description is the only source of information about the returned DataFrame. It merely states 'national tax revenue' and the type, without specifying columns, time range, frequency, or data source details beyond a bare URL. This is insufficient for an agent to fully understand what data it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter semantics to clarify. Per the rubric, the baseline for a zero-parameter tool is 4, and the description does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'China - National tax revenue' and states that it returns a pandas DataFrame of this data, adding the source URL. Although it lacks an explicit verb like 'retrieve' or 'list', the intent is unambiguous. It does not differentiate from sibling tools beyond the name, but the resource and return type are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions, prerequisites, or alternative tools for related data (e.g., other macro_china_* tools). This absence leaves the agent without decision support for tool selection.
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 already cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description only needs to add behavioral context. It adds the source URL and return type (pandas.DataFrame), but does not disclose potential failure modes, rate limits, or how the path interacts with the NBS website.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line title, the source URL, a standard docstring-style parameter list, and the return type. Every line earns its place and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This generic tool has no output schema and only sparse annotations, so the description must explain how to use it. It provides the source URL and parameter basics, but does not explain how to discover valid path values, what the returned DataFrame columns are, or how to map a user's data needs to a kind/path combination. This leaves a critical gap for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It provides a Chinese label for each parameter (kind, path, period) and gives concrete examples for period ('LAST10', '2016-2023', '2016-'). However, path remains vague as '数据路径' without explaining where valid paths come from or how to construct them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies this as the National Bureau of Statistics national data general interface and states it returns a pandas DataFrame of statistical data. It is clearly a generic data retrieval tool, but it lacks an explicit action verb like 'retrieve' or 'query', and while it distinguishes itself from specific macro_china_* siblings by being a '通用接口', it does not state exactly what data it returns beyond '统计数据'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 generic tool versus the many specific macro_china_* functions (e.g., macro_china_cpi, macro_china_pmi). It does not mention alternatives, exclusions, or conditions that favor this 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?
Beyond the readOnlyHint and idempotentHint annotations, the description adds the URL source and the return type (pandas.DataFrame). This provides some context about the data origin and format, but it does not disclose other behavioral traits such as whether the data covers all historical periods or the latest value only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the title and source URL. However, it repeats the index name in the title and the :return: line, which is slightly redundant. Overall, it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless data retrieval tool with strong annotations, the description is mostly adequate. It states the source and return type but does not explain the data structure (e.g., columns, frequency) or differentiate from similar PMI tools. Given the lack of an output schema, a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the baseline is 4. The description does not mention parameters, but since there are none, no additional semantic explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the China Purchasing Managers' Index from East Money, with a specific resource URL. However, it does not differentiate itself from sibling tools like macro_china_pmi_yearly or macro_china_cx_pmi_yearly, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, contexts, or typical use cases. The only implied guidance is that it returns PMI data, but this is not explicit.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), but does not disclose behavioral traits such as update frequency, coverage limitations, or any quirks. This is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but includes a URL and the phrase '邮电业务基本情况' appears in both the title and the :return: line, creating redundancy. It is not structured with an action-first verb and mixes human-readable text with docstring-like syntax.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, fixed-data retrieval tool, the description provides the data topic, source, and return type, which is reasonably complete. It does not describe the DataFrame's columns or index, but since there is no output schema and the dataset is named, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (empty schema), and the description correctly implies a no-argument call. With no parameters to document, the baseline score is 4, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: '邮电业务基本情况' (postal and telecommunications business basic situation) from Sina Finance macro data. However, it lacks an explicit action verb like 'get' or 'return', instead using a noun phrase. It distinguishes from siblings by naming the exact data domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions or alternative tools for similar macro data. The only signal is the data name itself, which implies usage but does not explicitly state it.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose other behavioral traits like rate limits, data freshness, or potential errors. It is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and to the point, containing only the data name, source URL, and return type. It avoids unnecessary words, though the structure is more like a fragment than a coherent sentence. Still, every piece of information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return value. It does specify that a DataFrame is returned and names the index, but it does not describe columns, date ranges, or data granularity. This is adequate for a simple no-parameter tool but lacks depth for a richer understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the description does not need to explain parameter details. The baseline score of 4 applies because there are no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides China's enterprise commodity price index data from Eastmoney, identifying the specific resource and source URL. However, it lacks an explicit action verb like 'get' or 'fetch', and does not explicitly differentiate from similar sibling tools such as macro_china_commodity_price_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus other economic data tools. It only states what data is returned, without any context on suitable scenarios 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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the data range (20170103-present) and return type (pandas.DataFrame), which is useful but does not disclose additional behavioral details such as update frequency or data volume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes a URL, return type, and data range. The ':return:' and ':rtype:' lines are slightly redundant with the title, but the overall structure is clean and free of excessive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only tool, the description provides essential information: purpose, data range, source URL, and return type. However, it lacks details such as update frequency, data granularity, or whether the data is historical daily rates. The annotations cover safety, so the core context is present but not fully developed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter descriptions needed. The description's mention of the data range is helpful context but not required for parameter semantics. The schema coverage is 100% with no parameters, making the baseline appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the China RMB exchange rate central parity report with a specific data range (20170103-present), which distinguishes it from sibling macro tools. However, it lacks an explicit verb like 'retrieve' or 'fetch', relying on the ':return:' docstring to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other RMB or macro tools. It does not mention alternatives, prerequisites, or typical use cases. The data range and URL provide some context but no direct usage direction.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), which is useful, but it does not disclose data granularity, update frequency, or potential scraping/network behavior. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short, containing a title, URL, and docstring-style return info. It is front-loaded with the title, but there is no explanatory sentence about the data itself. It is concise with no wasted words, yet slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter retrieval tool, the description gives the source and output type, but it omits what columns, time periods, or data granularity the returned DataFrame contains. Since there is no output schema, the description should provide more detail about the returned data to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty with 100% schema description coverage. Per the rubric, the baseline for 0 parameters is 4, and the description does not need to add parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (社会融资规模增量统计) and provides the source URL, making clear it returns social financing scale increment statistics. However, it lacks an explicit verb like 'fetch' or 'get', and does not explicitly differentiate from sibling macro tools, though the title is specific enough to imply the 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/5Does 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 such as macro_china_money_supply or macro_china_pmi. The description does not mention data coverage, update frequency, or any prerequisites, leaving the agent without context for selection.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is useful context, but it doesn't disclose data freshness, column structure, or any potential fetching issues. With annotations doing heavy lifting, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the title, followed by the source URL and return type in standard structured format. It wastes few words, though the first line duplicates the annotation title, which is a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only fetcher with strong annotations, the description is minimally viable: it specifies the data source and return type. However, there is no output schema, and the description does not elaborate on the actual columns, data granularity, or meaning of 'classification' beyond the title, which could be important for an AI agent deciding if this meets a user's request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so the description carries no parameter burden. Per the guideline, a baseline of 4 is appropriate when there are no params to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a table of China's total society electricity consumption classification from Sina Finance, and the specific topic distinguishes it from sibling macro tools. However, the verb is implicit ('return' rather than an explicit action like 'fetch'), so it's clear but not maximally 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives, such as related macro_china_energy_index or macro_china_daily_energy. There are no exclusions, prerequisites, or contextual hints about selecting this over other macro data 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the data source URL and return type, which is useful but does not disclose any additional behavioral traits such as data freshness, time range, or potential limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the tool's title and source, followed by a URL and return type. It is appropriately sized for a zero-parameter tool and contains no filler, though the URL fragment is somewhat cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description is mostly adequate, but it does not describe the structure of the returned DataFrame or any specifics about the data (e.g., time period, units, or columns). Given the lack of an output schema, a bit more detail about the data content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is trivially complete. With no parameters to explain, the description need not compensate for parameter documentation. The absence of parameters is clear from the schema, so the description's mention of the return type is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing China's total social passenger and freight transport volume from Sina Finance, with the URL as a source reference and the return type specified as a pandas DataFrame. It is distinct from sibling macro tools because it specifically targets traffic volume data, but the description lacks an explicit verb like 'fetch' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions, prerequisites, or typical scenarios, leaving the agent to infer usage from the name and source alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description does not contradict. The description adds the return type (pandas.DataFrame) and source URL, which is useful. However, it does not disclose what columns or data range are included, so behavioral insight is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, including a source URL and return type in a structured docstring format. No extra fluff, but the inclusion of a URL and docstring markers is slightly verbose for a zero-param tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description does not explain what fields or statistics are included in the DataFrame. The tool name mentions 'stock_market_cap' while the description says 'trading statistics', creating potential ambiguity about the actual data content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers inputs. The baseline is 4, and the description does not need to add parameter details. It correctly mentions the return type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '全国股票交易统计表' (national stock trading statistics) from East Money, and states the return type as pandas.DataFrame. While it omits an explicit verb like 'get' or 'list', the intent to fetch this table is clear and distinguishable from sibling macro 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/5Does 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 gives a source URL but no context, prerequisites, or exclusions. An agent must infer its applicability from the title alone.
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 already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering safety. The description adds the return type and a data source URL but no further behavioral traits such as update frequency, data range, or access limitations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief yet front-loaded, consisting of a title, URL, and return annotations. It is waste-free but fragmentary, reading more like a docstring header than a coherent instruction. For a simple no-parameter tool this is appropriate, though it could use one sentence of explanation without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only retrieval), the description is minimally sufficient, but it fails to explain what the returned DataFrame contains (e.g., columns, time range, index history). With no output schema, the description must carry that burden, and it only states the type. It is not egregiously incomplete relative to similar tools but lacks useful detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters and the schema provides 100% coverage (empty object). With zero parameters, the baseline is 4, and no description compensation is needed. The description adds no parameter mechanics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '义乌小商品指数-电子元器件' (Yiwu Small Commodity Index – Electronic Components) with a source URL and a return type of pandas.DataFrame. This clearly names a specific resource and distinguishes it from sibling index tools like macro_china_energy_index, though it lacks an explicit action verb such as 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No mention of use cases, prerequisites, or exclusions. The description simply states what the index is, providing no contextual direction for selecting it over related macro/economic index 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the data range spans from a specific start date to the present and that the return type is a pandas.Series. It also includes source URLs. This adds some context beyond the annotations, though it does not disclose any potential network behavior or update cadence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a mix of a Chinese sentence, two long URLs, and docstring-style return info. It is not overly long, but the URLs are extraneous for tool selection and could distract. The main description is front-loaded, but the structure feels cluttered with reference material.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description covers the essential points: what data is returned, the date range, and the return type. The frequency (quarterly) is implied by the name and description. Minor issues include a typo in the start date ('20083017') and no explicit statement of whether values are seasonally adjusted (though the title says so). Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description clarifies the output meaning (current value in percent) and the data source, which is helpful for invoking the tool correctly. No parameter explanations are needed because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: '欧元区季调后就业人数季率报告' (Eurozone seasonally adjusted employment change quarterly report) and states the return value as the current value in percent. It is distinct from sibling tools because it specifies the exact macro indicator. However, there is no explicit verb like 'Get' or 'Fetch', though the ':return:' line implies a query function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios, exclusions, or comparisons with sibling macro_euro_* tools. The only implied usage is when this specific data point is needed, which is not explicit.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, read-only operation. The description adds the data range and return type, which provides some behavioral context. However, there is potential ambiguity: it mentions '今值' (current value) but the return type is a pandas.Series, leaving unclear whether the output is a single latest value or a full time series. This is not a contradiction with annotations, but it does not fully clarify behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core information: report name and data range. The URLs are useful references and the return type is stated. However, the formatting is a bit informal and the URLs consume space, but overall every sentence has a purpose. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description should clarify what the returned data looks like. It states the return type as pandas.Series and mentions '今值' (current value), but does not explain whether the series contains historical data or just the latest observation, nor does it describe the index or units. The data range is given, but the ambiguity about the series content makes the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The description does not need to explain parameters, and the baseline for 0-parameter tools is 4. The description adds no parameter information, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides the Eurozone Sentix investor confidence index report with a specific data range (20020801 to present) and return type. Although there is no explicit action verb like 'retrieve' or 'query', the combination of the report name, data range, and return type makes the purpose clear. It is distinct from sibling macro_* tools because it uniquely targets the Sentix confidence index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative macroeconomic data tools. The description does not mention any exclusions, prerequisites, or scenarios where this tool is preferred. It only provides the data source URLs, which do not help with tool selection decisions.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is some context, but it does not disclose any behavioral traits such as the historical range covered, data frequency, or that it fetches from a live web endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of a title line, a URL, and a return-type docstring. It is efficient and front-loaded, with no wasted words. However, it reads more like a mechanical docstring than a thoughtfully written description, so it doesn't earn the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple no-parameter retrieval, and the description states the source URL and return type, which is sufficient for a basic invocation. But it lacks information about the data's time span, update frequency, or any caveats, and there is no output schema to fill those gaps. It is minimally complete but leaves open questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description adds no parameter details, but none are needed. Per the baseline for 0-parameter tools, this scores 4 because the schema fully documents the absence of parameters and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Germany's Consumer Price Index yearly rate final value from Eastmoney's data center. The title and URL provide specific context, but there is no explicit verb like 'retrieve' or 'get'; the purpose is implied by the name and title rather than stated directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative macro data tools, such as macro_germany_cpi_monthly or macro_germany_gdp. The description does not mention exclusions, prerequisites, or comparison to sibling tools, so the agent must infer usage purely from the name.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and a source URL, which is useful but does not disclose additional behavior such as data frequency, date range, or pagination. It does not contradict annotations, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of the title, a URL, and a return-type annotation. It is well-structured with clear labels for return and rtype. No unnecessary words. However, it is almost too terse, lacking any explanatory prose that could help an agent understand the tool's broader role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential context: the data is Germany's ZEW index from a specified source, and the return type is a DataFrame. Yet it omits critical details like time range, frequency, or the columns included in the DataFrame. Without an output schema, the description carries the burden of explaining the return value, but it only states the index name. This is enough for a basic retrieval but not richly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). The description does not need to elaborate on parameters. It mentions the return value, which is relevant context for a parameterless function. Baseline for 0 params is 4, and the description satisfies this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Germany's ZEW Economic Sentiment Index, sourced from Eastmoney's data center. It states the return type and a URL, making the tool's primary purpose apparent. However, it lacks an explicit verb (e.g., 'retrieves' or 'returns'), leaning on the name and title to convey action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives. Sibling tools include macro_euro_zew_economic_sentiment and other Germany-specific macro indicators, but the description does not differentiate or provide context for choosing this tool. It simply provides a title and URL, leaving the agent without usage criteria.
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 already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds the return type (pandas.DataFrame) and a source URL, which are useful. However, it does not disclose other behavioral traits such as data frequency, time range, or whether the data is historical or real-time. With good annotation coverage, this is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of the index name, a URL, and a docstring. There is no fluff or redundancy beyond the repeated name, but the raw URL adds a practical source reference. The structure is reasonably clean, though it could be more readable if the URL were presented as a label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only tool, this description is minimally viable. It names the index and its source, and specifies the return type. However, it does not clarify whether the returned DataFrame contains historical time series or just a current snapshot, nor does it describe the columns or time span. Given no output schema exists, the description should provide more detail about the data structure to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The description correctly indicates the return type (DataFrame), which is the only relevant semantic. The schema is empty, so the description adds value by stating the return structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the Philadelphia Semiconductor Index (费城半导体指数) and provides a data source URL. While it lacks an explicit action verb like 'get' or 'return', the docstring ':return: 费城半导体指数' and the tool name make it evident that the tool returns this index data. It distinguishes itself from siblings by being specifically for the SOX index, but the phrasing is minimal and relies on the name/context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where this index would be preferred over other macro/index tools. The agent is left to infer usage solely from the name and description.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context—only that the return type is pandas.DataFrame. It does not mention any pagination, rate limits, or data completeness, but for a simple read-only data retrieval with no parameters, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, containing only the source label, URL, and return type. However, the formatting is somewhat unstructured with the URL embedded, and the ':return:' line redundantly repeats the title. Despite this, every part adds some information and there is no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description should at least clarify what the returned DataFrame contains. It only says '央行公布利率决议' (central bank interest rate decision), which is vague about columns, historical coverage, or data structure. The low complexity makes this minimally viable, but more detail would help an agent understand the exact data returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema carries full coverage (100%). The description does not need to explain parameters, and it doesn't. The baseline of 4 for zero-parameter tools applies, and the description's mention of the return type adds a small but useful detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Japan's central bank interest rate decisions from Eastmoney economic data, with a specific source URL. While it lacks an explicit verb like 'get' or 'returns', the title and context make the purpose unambiguous. It does not explicitly differentiate from similar sibling tools like macro_bank_japan_interest_rate, but the specific data source and wording make its scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 many sibling tools, including macro_bank_japan_interest_rate and other Japan macro indicators, make this a significant gap. A sentence indicating that this tool is for interest rate decision announcements rather than current rate levels would be valuable.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the return type (pandas.DataFrame) and source URL, which are useful but minimal. It does not mention any potential limitations, such as data frequency, date range, or network dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a title, URL, and two docstring lines. It is appropriately sized for a zero-parameter tool. However, there is redundancy: the title '人民币存款余额' is repeated in the :return: line. Still, every piece of information is relevant and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description provides basic information: source, data type, and return type. However, it does not explain what the returned DataFrame contains beyond '人民币存款余额'—such as time series frequency, columns, or historical depth. Given no output schema, more detail about the return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema has full coverage by definition. The description adds no parameter information, which is acceptable given there is nothing to document. The baseline for 0-param tools is 4, and there are no gaps to penalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving RMB deposit balance data from Flush Data Center, with the return type specified as pandas.DataFrame. However, it lacks an explicit verb like 'retrieve' or 'get', and does not distinguish itself from similar macro tools such as macro_china_rmb or macro_rmb_loan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states the source and return type, with no mention of use cases, prerequisites, or when not to use it. There is no comparison to sibling tools like macro_china_rmb.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), but it does not disclose whether the data is scraped, how fresh it is, or the DataFrame's columns/units. It provides some context but does not substantially go beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear label, source URL, and return annotation. It is front-loaded with the indicator name and contains no filler. The structure is a bit docstring-like rather than a full sentence, but it is efficient and every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only tool, the description provides the essential source and return type, but it omits specifics like data periodicity (monthly?), the exact columns in the DataFrame, and whether it returns historical series or only the latest value. Since there is no output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially complete. The description does not need to explain parameter meaning, and the baseline of 4 is appropriate since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing new RMB loan (新增人民币贷款) macro data from THS Data Center, with a source URL and return type. It distinguishes itself from sibling tools like macro_rmb_deposit and macro_china_new_financial_credit by naming the specific indicator, though it lacks an explicit action verb like 'fetch' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_china_money_supply or macro_china_new_financial_credit. The description does not mention data frequency (e.g., monthly), date ranges, or any constraints, leaving the agent with no criteria for choosing it over similar macro 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds a source URL and a return type (pandas.DataFrame), which provides some context beyond the title, but does not disclose additional behavioral traits such as data frequency, date ranges, or potential parse failures. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the key identifier (BCTI), followed by a source URL and return type. However, the ':return:' line partially repeats the title, making it slightly redundant. Still, the structure is efficient and not verbose, earning a strong score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is mostly adequate, but it lacks details about the DataFrame's contents, such as columns, time range, or update frequency. The URL provides a hint about the data source, and the return type is stated, but without an output schema, more descriptive detail would help the agent understand what data is returned. Slightly below the higher end due to this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter semantics. The baseline of 4 applies because no parameters exist and the description correctly implies no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the refined oil transportation index (BCTI) and states it returns that index via the ':return:' line. Although no explicit verb like 'fetch' or 'get' is used, the resource is specific and distinct from the many shipping/macro sibling tools. Lacks explicit differentiation from siblings, but the name and return statement make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_shipping_bdi, macro_shipping_bpi, or macro_shipping_bci. The description does not mention any context, exclusions, or alternatives, leaving the agent without decision support for tool selection.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to restate safety. It adds a source URL and return type (pandas.DataFrame), but does not disclose data frequency, historical scope, or any quirks of the data source. With annotations covering the safety profile, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three lines) and gets to the point quickly. However, the first line duplicates the title, and the docstring-style return statement adds minimal value. The URL is useful but makes the description a bit noisy. Overall, it is appropriately sized but not perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with annotations and no output schema, the description gives a source URL and return type, which is a reasonable baseline. However, it lacks details about the DataFrame contents (e.g., columns, date range, unit) and whether it provides historical data or just a snapshot. This is adequate for a simple tool but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. The baseline for parameter semantics is 4, and the description does not need to explain any parameters. It does confirm the return type, which is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns the 巴拿马型运费指数 (BPI), which is a specific resource. It distinguishes from sibling shipping indices (BCI, BDI) by its name and title, though the description itself is mostly a restatement of the title with a source URL and return type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative shipping index tools. It does not specify that it is specifically for BPI or compare with related tools like macro_shipping_bdi, leaving the agent with no contextual selection cues.
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 already establish the read-only, idempotent, non-destructive profile, so the bar for additional disclosure is lower. The description adds the source URL and the pandas.DataFrame return format, which is useful context, but it reveals nothing about columns, time ranges, pagination, or data freshness. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the data source label and URL. However, the line ':return: 股票筹资' largely restates the title, making it slightly redundant, while the rtype line adds genuine information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return value shape, but it only gives the topic (股票筹资) and container type. The DataFrame's columns, units, and temporal scope are unspecified, which is a notable gap, though the zero-parameter design keeps overall complexity low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers inputs and the baseline of 4 applies. The description's return-type note ('pandas.DataFrame') adds marginal value, and there are no undocumented parameters to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly labels the data resource (同花顺-数据中心-宏观数据-股票筹资, i.e., THS Data Center macro stock financing) and states that it returns a pandas DataFrame of 股票筹资 data, making the basic purpose evident. However, it lacks an explicit action verb and does not differentiate itself from sibling tools like macro_china_stock_market_cap or stock_financial_abstract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is purely a data-source label with a URL and return type, with no mention of appropriate scenarios, exclusions, or preferred sibling 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a return type (DataFrame) and a source URL, but does not disclose any additional behavioral traits like data frequency, date range, or potential issues. This is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact: a title line, a URL, and a return type/return value docstring. It contains no wasteful prose. However, the first line is more of a header than a full descriptive sentence, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, the description conveys the source, indicator, and return type. However, it lacks any information about the returned DataFrame's structure (columns, date range, frequency). This is acceptable given the simplicity, but leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% by default. With no parameters to describe, the description's omission is not a gap. The baseline of 4 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the SVME Purchasing Managers' Index for Switzerland from East Money, naming the specific country and indicator. However, it uses a noun-phrase (title) rather than an explicit verb like 'get' or 'fetch', and does not distinguish itself from sibling macro tools 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/5Does 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 such as macro_swiss_cpi_yearly or macro_china_pmi. It simply states the data source and return type, with no mention of selection criteria, prerequisites, 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the source URL and return type (pandas.DataFrame) but does not disclose additional behavioral characteristics like data frequency, update timing, or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and follows a clear structure: title, source URL, and return type. It is front-loaded with the core purpose and avoids unnecessary details, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only states the return type as pandas.DataFrame, not the actual columns, range, or units. While the tool is simple, an agent might need more details about the expected data structure to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information to add or clarify; the description is not lacking in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing UK CPI monthly data from Eastmoney. It specifies the source, country, metric, and period. However, it lacks an explicit verb like 'get' or 'fetch', reading more as a title than a command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related siblings such as macro_uk_cpi_yearly or macro_uk_core_cpi_monthly. There are no exclusions, conditions, or alternative suggestions.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose data granularity, columns, update frequency, or any caveats about the scraping source. This is modest added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a title line, URL, and return docstring. It wastes no words and is front-loaded with key identifying information. However, the structure reads more like a code comment than a coherent narrative, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description provides essential identification and return type, which is minimally adequate. However, without an output schema, it does not describe the DataFrame's columns, time range, units, or other details, leaving an agent uncertain about the exact output format beyond the indicator name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully self-descriptive (100% coverage). The description confirms the return type but adds no parameter semantics, which is appropriate and consistent with the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the source (Eastmoney/东方财富), country (UK/英国), and indicator (CPI yearly rate/消费者物价指数年率), with a URL for the data page. This clearly distinguishes it from siblings like macro_uk_cpi_monthly or macro_uk_core_cpi_yearly, though it lacks an explicit verb such as 'get' or 'return', making it more of a label than a complete sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related tools like macro_uk_cpi_monthly or macro_uk_core_cpi_yearly, nor does it provide selection criteria. The only implicit signal is the tool's name and the indicator label.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context, only mentioning the source URL and that it returns a DataFrame. It does not disclose update frequency, data granularity, or potential external dependencies beyond the URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, structured with docstring markers (:return:, :rtype:) and a source URL. It is front-loaded with the metric name. The URL adds some clutter but serves as provenance. Overall, it is efficiently written with no redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description should clarify the return structure. It only states 'GDP 年率初值' as the return, which is the metric name, without indicating columns or date range. For a simple no-parameter tool, this is somewhat adequate but leaves ambiguity about the DataFrame contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 correctly omits parameter details, and the schema confirms no parameters exist. The mention of return type is irrelevant to parameter semantics but does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning UK GDP annual rate preliminary values from Eastmoney, which is a specific resource. It distinguishes from the sibling tool macro_uk_gdp_quarterly by specifying the yearly metric. However, it lacks an explicit action verb like 'get' or 'retrieve', relying on the tool name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, exclusions, or related tools, despite a large sibling set with similar macro economic indicators.
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 already declare readOnlyHint, idempotentHint, and destructiveHint: false, covering the safety profile. The description adds the data source URL and return type, but does not disclose additional behavioral traits such as date range, data granularity, or any rate limits, which is acceptable given the annotations but adds only marginal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact stub with four short lines, each serving a purpose: dataset origin, URL, return value, and return type. It is appropriately brief for a simple tool, though it could be more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool, the description names the dataset, source, and return format, which is minimally adequate. However, it omits details about the output content (e.g., columns, time series coverage), leaving some ambiguity about what the DataFrame actually contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 add parameter semantics and does not attempt to, which is appropriate for this empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing UK trade balance data from East Money, complete with a source URL and return type (pandas DataFrame). It is specific enough to distinguish from sibling macro_uk_* tools covering CPI, GDP, etc., though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_uk_cpi or macro_uk_gdp. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds minimal context: it returns a pandas DataFrame of unemployment rate from Eastmoney. No additional behavioral traits (e.g., pagination, data update frequency) are disclosed, but nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing the source name, a URL, and a return specification. It is front-loaded with the purpose and does not waste words. However, the URL line is somewhat terse and could be considered extraneous, though it does add source credibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description provides the essential return type and indicator, but it lacks details such as the frequency of the data (e.g., monthly, quarterly), the columns included in the DataFrame, or how the data is structured. Given the simplicity, this 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly states the return type (pandas.DataFrame) and the content (unemployment rate), which is sufficient since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving UK unemployment rate data from Eastmoney economic data. It names the specific indicator and source, distinguishing it from sibling tools like macro_uk_trade or macro_uk_bank_rate. However, it lacks an explicit verb like 'get' or 'fetch', relying on the tool name for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description only provides a source URL and return type, with no mention of when to prefer this over other UK macro indicators or any exclusions. Users must infer usage from the tool name.
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 already cover readOnly, idempotent, and destructive safety traits, lowering the burden. The description adds value by providing the date range and source URL, but lacks details on update frequency, units, or interpretation, leaving room for more 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose and data range. The docstring remnants ':return:' and ':rtype:' are slightly redundant but not disruptive, keeping the description efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, it provides the report name, date range, source URL, and return type. Missing context includes the actual data content (e.g., employment change in thousands), frequency, and how to interpret the series, making it adequate but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 appropriately notes the return type as pandas.Series, which adds a bit of semantic clarity even though no parameters exist to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the US ADP employment report (美国ADP就业人数报告) and the data range since 2001-06-01. It specifies the resource and scope, but does not explicitly distinguish it from sibling macro_usa_non_farm, so it loses a point for missing differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like macro_usa_non_farm or other employment indicators. The description simply states what the tool returns without any contextual 'when to use' 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?
Annotations already cover the safety profile (read-only, idempotent, non-destructive). The description adds the data source URL and return type (pandas.DataFrame), but does not disclose behavior such as column names, units, or update frequency. With annotations doing most of the work, the added value is modest but non-zero.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at three lines, with the purpose, data source, and return type clearly stated. However, the return type is mentioned twice (in ':return:' and ':rtype:'), which is a minor redundancy. No fluff, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only tool, the description provides the essential purpose and date range, but lacks details about the returned DataFrame's contents, such as columns, units, or how the monthly rate is calculated. With no output schema to fill this gap, the description is adequate but not complete for someone needing to interpret the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers 100% of parameters. The description does not need to explain parameter semantics. It does note the return type, which is helpful context beyond the empty schema. Baseline 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a US business inventories monthly rate report, specifying the data range (19920301-present). It clearly indicates the resource and frequency, and while it lacks an explicit verb like 'retrieve', it is clear that the tool returns this report data. The name itself is highly descriptive and matches the description, adding minimal additional distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other macro indicators or siblings. The description does not mention any alternatives, prerequisites, or exclusions. Users are left to infer that it is used for US business inventory data from the name and brief content.
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 already declare the tool as read-only, idempotent, open-world, and non-destructive, so the description does not need to restate safety. The description adds the data interval and source URL, which are useful contextual details beyond annotations. However, it does not disclose potential return volume, data granularity, or any limitations, leaving some behavioral ambiguity for a DataFrame-returning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of a main sentence, a source URL, and standard Python docstring return lines. It front-loads the key identifying information. Some redundancy exists between the main sentence and the ':return:' line, both stating the report name, but overall the length is appropriate and free of unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description specifies the report type, date range, and return type (pandas.DataFrame), providing a foundational understanding. However, with no output schema, it does not describe the DataFrame's columns, data structure, or possible units, which an agent might need to interpret the result correctly. Given the tool's simplicity and zero parameters, the lack of output details is a moderate gap but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there are no parameter semantics to explain. The description does not add or contradict any parameter details. With no parameters, the baseline of 4 is appropriate because the schema trivially covers all parameters, and the description's mention of the date range is not parameter-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as the CFTC commodity commercial holdings report (商品类商业持仓报告) with a specified date range (19860115 to present). It clearly indicates a data retrieval function returning a pandas DataFrame, and the '商品类' qualifier helps distinguish it from currency or other holding types among sibling tools. However, it lacks an explicit verb like 'fetch' or 'query,' relying on the report noun and tool name to convey 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/5Does 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 macro_usa_cftc_merchant_currency_holding or macro_usa_cftc_c_holding. It only states the data range and source URL, implying it covers historical CFTC commodity merchant holdings from 1986 onward, but does not explicitly state conditions or exclusions. This is a clear gap for an agent deciding among many similar CFTC/CME holding 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the return type (pandas.DataFrame) and date range, which is useful, but it does not explain the data semantics (e.g., what columns, update frequency) or any caveats. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the key information (data name and range) in the first line. The embedded URL and repeated return-type line add minor redundancy but do not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool, the description covers the essentials: what data, the date range, and the return type. However, it leaves ambiguity about the exact contents of the DataFrame (e.g., which precious metals, holdings vs. prices) and offers no source context beyond a bare URL, so it is only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object with 100% coverage. The description's mention of the return type and data range adds value beyond the schema, which is sufficient for a parameterless function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (CME precious metals) and specifies the data range (since 20180405), making the tool's purpose fairly clear. It lacks an explicit verb like 'get' or 'return', but the name and title together settle that it provides CME merchant goods holding data. It is distinguishable from siblings by the CME vs CFTC distinction embedded in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_usa_cftc_merchant_goods_holding or crypto_bitcoin_cme. The description only states the resource and date range, leaving the agent to infer usage from the name.
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?
The annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds useful context about the data range (since 1970) and the return type (pandas.DataFrame), plus a source URL. However, it doesn't disclose details about the DataFrame's contents, columns, or potential time zones, so it adds limited 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately compact, with the key information front-loaded. Slight redundancy exists in repeating the report name in the :return: line, but overall it's concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool with no parameters, the description provides the essential scope (data range) and return type. However, it lacks details about the DataFrame's structure, such as columns or the meaning of '月率', which could matter for an agent deciding on data extraction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to clarify. The baseline of 4 applies, and the description doesn't need to compensate for a low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a US CPI monthly rate report with a specified data range and a source URL. It's specific about the resource and frequency, though it doesn't explicitly differentiate from related CPI tools like core CPI or YoY variants beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't mention when to use this tool versus alternatives like macro_usa_cpi_yoy or macro_usa_core_cpi_monthly, nor does it specify any prerequisites or context.
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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the data range, a source URL, and the return type (pandas.DataFrame), which are useful behavioral details. However, it does not disclose data frequency, units, columns, or any other operational traits, so it adds moderate but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, then the source URL, and ends with return type. It is appropriately sized, though it repeats '美国原油产量报告' twice, which is a minor redundancy. Overall it earns its place without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description conveys the essential purpose, date range, and return type. However, it lacks specifics such as data frequency (daily/weekly), units (barrels per day?), or list of DataFrame columns. Since there is no output schema, these details would have improved the description, but the basic information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivial (100% empty). The description correctly shows no parameters are needed, and the baseline for 0-parameter tools is 4. There is no need for additional parameter semantics because there is nothing to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing a U.S. crude oil production report with an explicit date range (19830107 to present). Although it lacks an explicit verb like 'get' or 'retrieve', the return annotation and data range make the purpose unambiguous. It distinguishes from sibling tools like macro_usa_eia_crude_rate and macro_usa_api_crude_stock by focusing specifically on production.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states what the report is and gives a date range, but does not mention any conditions, exclusions, or mention of sibling tools. There is no indication of when the user should choose this over other crude-oil-related tools, leaving the agent without direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds a data range (19950801-present) and a source URL, which is useful context, but it does not mention update frequency, units, or potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with no redundancy. The inclusion of a source URL and return type is helpful, though the lack of any explanatory sentence beyond the title makes it slightly sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description covers the basic purpose and return type, but since no output schema is provided, it should describe the shape of the DataFrame (columns, units, frequency). The date range and URL help, but the description is minimal for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meaning. The schema is empty and fully covers all parameters (none), making the baseline 4 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the US EIA crude oil inventory report, with a specific data range and source URL. It is a specific resource, but it lacks a verb like 'retrieves' or 'returns' and does not explicitly differentiate from sibling tools such as macro_usa_api_crude_stock or macro_usa_crude_inner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention excluded scenarios, prerequisites, or how it differs from similar crude oil data 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context about the data range and that it returns a pandas.Series. However, it does not disclose potential quirks like update frequency or handling of missing values, so it stops at adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but cluttered with two long URLs and Python docstring-style return/rtype lines. It front-loads the core meaning but includes extraneous source URLs that are not essential for tool invocation. It is acceptable but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description covers the essential context: what data is returned (US Export Price Index current value), the historical range, and the return type (pandas.Series). It lacks details on data frequency but is otherwise sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description has no parameter semantics to explain. The baseline for 0 params is 4, and the description appropriately adds return type and data range context without needing to clarify input fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the US Export Price Index report with a data range from 1989-02-01 to present, and specifies the return value as the current value (%). Although it lacks an explicit verb, the resource and output are unambiguous. It also distinguishes itself from the sibling macro_usa_import_price by focusing on export rather than import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Among the many macro_* siblings, there is no indication of preferred use cases, exclusions, or comparisons to tools like macro_usa_import_price. The agent is left to infer usage context solely from the name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the date range and return type (pandas.DataFrame), which is useful but does not go beyond that. It doesn't disclose any additional behavioral traits like update frequency or source behavior, but for a simple read-only report, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first sentence and the :return: line essentially repeat the same information. The URL is not useful for an agent and the structure is a bit disjointed. It's not overly verbose, but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description provides the essential information: what data it returns (US factory orders monthly rate), the date range, and the return type. It does not explain what '月率' (monthly rate) means or whether the data is a full historical time series, but the context is mostly sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description adds value by stating the data range and return type, but there are no parameters to explain. With no parameters, the description appropriately carries no parameter burden, earning the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the tool as a US factory orders monthly rate report and specifies the data range (19920401-present). The :return: line also confirms it returns this report as a pandas DataFrame. While it lacks an explicit action verb like 'fetch' or 'return', the intent is clear and distinguishes it from sibling macro 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/5Does 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 instead of other macro_usa_* alternatives. The description simply states what the tool provides, leaving the agent to infer that it should be used when US factory orders data is needed. No exclusions or alternative tool references are given.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful context about the data range and source URL, plus the return type (pandas.DataFrame), but does not elaborate on frequency, columns, or limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core meaning. It includes a source URL and docstring-style return/type lines, which are useful. Slight redundancy with the title repeated in the return line, but overall compact and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description provides the essential metric, date range, and return type. However, it does not specify the data frequency (e.g., monthly) or any output columns, and it lacks sibling differentiation context, which is important given the large number of similar macro_usa_* tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully documents the absence of inputs. The description adds no parameter information, but none is needed. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the US new housing starts total annualized report with a specific date range (19700101-present). It is specific enough to distinguish from sibling tools like macro_usa_new_home_sales, though it lacks an explicit verb and does not directly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other macro_usa_* tools. It does not mention use cases, prerequisites, or alternatives, leaving the agent to infer selection purely from the name and description.
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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the data range, source URL, and return type (pandas DataFrame). However, there is ambiguity between '数据区间从 19700101-至今' and ':return: 今值' (current value), which could confuse the agent about whether the tool returns the full series or just the latest value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured with a main line, source URL, :return: line, and :rtype: line. It is front-loaded with the core purpose and contains no fluff. Slightly informal formatting but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential details: data range, source URL, return type. However, it fails to clarify whether the returned DataFrame contains the entire historical series or only the current value (今值). This ambiguity could impact the agent's expectations about the output structure. Also, no frequency (monthly, etc.) is specified, though the ISM PMI is commonly known to be monthly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% by definition. With no parameters to describe, the description need not add parameter semantics. The description does not introduce any parameter-like details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the US ISM Manufacturing PMI report with a date range from 19700101 to present. It distinguishes from sibling tools like macro_usa_ism_non_pmi by specifying '制造业' (manufacturing). However, it lacks an explicit action verb (e.g., 'get'), though the return type implies retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other PMI-related sibling tools. It does not mention alternatives or exclusionary conditions, leaving the agent to infer via the name and description alone.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the data range and source URL, which is useful context, but it does not disclose data update frequency, limitations, or how 'preliminary' differs from a final report. Given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the phrase '美国密歇根大学消费者信心指数初值报告' appears in the title, the first line, and the ':return:' line. The URL and ':rtype:' are useful, but the repetition makes it less concise than it could be. A single statement of the resource would be sufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool with strong annotations, the description provides the key context: the specific indicator, the full historical date range, and the return type as a pandas.DataFrame. It doesn't list columns or data frequency, but no output schema exists and the tool's simplicity makes this a reasonable level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 correctly does not introduce any parameter meaning since none exist. No additional parameter semantics are needed, and the empty schema fully covers this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific resource (University of Michigan Consumer Sentiment Index preliminary report) and provides the data range (19700301-present). It distinguishes itself from the numerous sibling macro tools by naming the exact indicator. However, it lacks an explicit action verb like 'fetch' or 'retrieve', instead using a noun phrase, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 suitable use cases, exclusions, or sibling tools. For a simple zero-parameter data retrieval tool, the context is implied but not stated, so the agent receives no explicit direction.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds useful context by stating the data range and that the return type is a pandas DataFrame. However, it does not disclose other behavioral traits such as update frequency, pagination, or whether it fetches from the provided URL, so it adds some but not rich value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a Chinese title sentence, a source URL, and a docstring-style return annotation. It avoids fluff and is easy to scan. The inclusion of the URL is a minor extra, but it provides reference value. It is slightly repetitive in that the return description echoes the title, but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and no output schema, the description covers the essential facts: what data (NFIB small business confidence), the historical range, and the return type. However, it does not specify the data frequency (e.g., monthly), the exact columns, or any special behavior like how recent the data is. For a simple read-only macro indicator 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is trivially fully covered. The description appropriately does not elaborate on parameters, and the baseline score for no parameters is 4. The return type is specified, which helps the agent understand output without needing an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the US NFIB Small Business Confidence Index report with a specific data range. It uses a specific resource noun phrase and implies retrieval, though it lacks an explicit verb like 'fetch' or 'get'. The name itself distinguishes it from sibling macroeconomic tools, even though the description doesn't explicitly compare with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the data range (1975-02-01 to present) and a source URL, but gives no explicit guidance on when to use this tool versus other macro_usa_* indicators. It does not mention alternatives or provide exclusion criteria. The context is implied by the tool's name, but the description itself offers no usage direction.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful context such as the data range starting from 19700102, the source URL, and the return type as pandas.Series, but does not elaborate on data structure, units, or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes the key details (title, data range, source URL, return type). However, the phrase '美国非农就业人数报告' is repeated three times, adding redundancy without increasing information value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned pandas.Series contains. It provides the indicator name and data range, but lacks specifics such as the index format (e.g., dates), units (e.g., thousands), and whether the series is monthly or annual. This leaves some ambiguity for an agent interpreting the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered and no parameter documentation is needed. The description correctly implies that no input is required, earning the baseline score of 4 for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the US non-farm payroll report, with a specific title and data range. It distinguishes from sibling tools like macro_usa_adp_employment and macro_usa_unemployment_rate by naming the exact indicator. However, it lacks an explicit action verb like 'get' or 'retrieve', relying on the tool name to convey the retrieval 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/5Does 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 related US macro indicators. The description does not mention alternatives or exclusions, leaving the agent to infer appropriate usage from the tool name alone.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the data start date and a source URL, which is useful context, but does not disclose update frequency, data granularity, or any other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: the phrase '美国成屋签约销售指数月率报告' appears twice, and the :return line repeats the title. The URL and rtype are useful, but the repetition wastes space and could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool, the description is fairly complete. It states the report type, data range, and return type (pandas.DataFrame). There is no output schema, but for a simple time-series report, this level of detail is adequate. It could mention update frequency or column structure, but those are not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers 100% of parameters. According to the rubric, 0 parameters merits a baseline score of 4. The description adds no parameter information because there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the US pending home sales index monthly rate report with a specific data range. It lacks an explicit verb like 'get' or 'retrieve', but the tool name and description make the function obvious. It is distinguishable from siblings like macro_usa_exist_home_sales by the metric name and the report type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_usa_exist_home_sales or macro_usa_new_home_sales. It only states the data range and return type, leaving the agent to infer usage from the name alone.
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 already declare the tool as read-only, non-destructive, and idempotent. The description adds useful context by specifying the return type (pandas.DataFrame) and the data range. It does not describe update frequency or data granularity, but the annotations cover the safety profile adequately, so the added information is sufficient for a basic transparency score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, including a source URL and return type in a clear docstring format. There is minor redundancy in repeating the report name, but no filler or unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the data range and return type, which is helpful for a simple zero-parameter read-only report. However, without an output schema, it does not disclose the structure of the returned DataFrame (e.g., columns, time aggregation). This is a gap, but the tool is simple and the annotations fill in the safety context, so the description is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema covers everything. The description correctly omits parameter details, and with no parameters to document, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a US personal spending monthly rate report with a specific date range (19700101-present). The resource is specific and the intent is clear, though it doesn't explicitly distinguish from sibling macro indicators like macro_usa_real_consumer_spending or macro_usa_retail_sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 are no mentions of use cases, exclusions, or comparative context despite the large set of sibling macro tools covering US economic indicators.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the data source URL and return type, but discloses nothing about data coverage, update frequency, or DataFrame contents. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—three lines (title, URL, return type) with no filler. The first line is redundant with the provided title, but the remaining lines earn their place by adding source and return-format context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is minimally adequate: it names the data, gives the source URL, and states the return type. However, with no output schema, it leaves unspecified what columns or historical coverage the DataFrame contains and how this tool differs from the similarly named sibling macro_usa_pending_home_sales.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies; there is nothing for the description to explain. The empty input schema already provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: US pending home sales monthly rate (未决房屋销售月率) from East Money, with the source URL and a pandas DataFrame return type. However, it is essentially a restatement of the title and does not differentiate this tool from closely related siblings like macro_usa_pending_home_sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling macro_usa_* economic data tools (e.g., macro_usa_exist_home_sales, macro_usa_new_home_sales, macro_usa_pending_home_sales). There is no mention of context, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data range (2008-02-26 to present), a source URL, and the return type (pandas.DataFrame), which provides useful context beyond the annotations. However, it does not describe any potential quirks, size, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and follows a typical docstring format (summary, URL, return, rtype). It is mostly concise, but there is redundancy: '美国生产者物价指数(PPI)报告' appears both in the description and in the ':return:' line. The URL is useful but could be placed as a reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool with no parameters and no output schema, the description gives key information: US PPI, date range, and return type. However, it does not describe the columns, frequency (monthly/quarterly), or units of the returned DataFrame, leaving the agent with ambiguity about the exact data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema. Per guidelines, the baseline for 0 parameters is 4. The description does not discuss parameters, but none exist, and it mentions the fixed data range, which indirectly clarifies that no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the US Producer Price Index (PPI) report with a specific date range ('数据区间从 20080226-至今'). This distinguishes it from related siblings like macro_china_ppi and macro_usa_core_ppi. However, the action is implicit (it says 'report' rather than a verb like 'get' or 'retrieve').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_usa_core_ppi or macro_usa_cpi_yoy. The description only provides a source URL and date range, with no mention of scenarios, exclusions, or preferred use cases.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context like data range (since 20131107) and return type (pandas.DataFrame), but omits details on update frequency or column structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four lines) and front-loads the core purpose and data range. The included URL and return type are useful, though the :return: line partly repeats the title. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool, the description covers the data range, source, return type, and safety (via annotations). However, it lacks details on DataFrame columns, update cadence, and any quirks of the 'preliminary' report, making it only adequately complete for an agent to select the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing to compensate for. The description adds no parameter details, but none are needed. The baseline of 4 for 0 parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving the US real personal consumption expenditure quarterly rate preliminary report, with a specific data range and source URL. It distinguishes from siblings like macro_usa_personal_spending by specifying 'real' and '季率初值' (quarterly rate preliminary), though no explicit verb like 'get' or 'fetch' is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives, and no exclusions or preferred contexts are mentioned. The specificity of the name implies a niche, but the description does not help an agent differentiate this from similar macro 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the data range (since 20010201) and return type (pandas.DataFrame), but does not detail the actual columns or any quirks, which is a minor gap given no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first sentence and the ':return:' line repeat nearly the same phrase. Still, it is front-loaded with the main topic, and the source URL adds useful context without bloating it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data tool with strong annotations, the description provides the indicator name, data range, source URL, and return type. It is sufficiently complete for an agent to invoke it, though it could be improved by mentioning the frequency or columns returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing to explain. Baseline for 0 params is 4, and the description does not introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the U.S. S&P/CS20-city home price index annual rate report, with a specific data range and return type. It is distinct among the many macro_usa_* siblings by naming the exact index and data source, though it lacks a strong verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention any exclusions or compare with related tools such as macro_usa_house_price_index, 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the source URL and exchange choices, but it does not disclose behavior such as data freshness, network dependency, error handling for invalid symbols, or the format of the returned string. This is acceptable given the read-only nature declared by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the source, parameter choices, and return type. It avoids unnecessary prose. However, the Chinese title duplicates the annotation title, and the long URL might be considered noise, though it does provide the data source. The structure is acceptable but could be improved by front-loading a clear verb phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, returns a string) and the annotations providing safety context, the description is mostly adequate. It covers the source and parameter choices, but it does not explicitly state what the function does beyond the return type, nor does it describe the format of the main contract string or behavior for invalid exchange codes. These are minor gaps for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the 'symbol' parameter, but the description compensates by explicitly listing the five valid exchange choices: {'czce', 'dce', 'shfe', 'cffex', 'gfex'}. It clarifies the expected values, which is essential since the schema only defines 'symbol' as a string with a default. It does not explain what each code means, but the list itself adds significant semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool returns the main futures contract string for a given exchange, with the Chinese title '新浪财经-期货-主力合约' and return type '主力合约的字符串'. However, it lacks an explicit verb phrase and does not differentiate from sibling tools like futures_main_sina or futures_display_main_sina, which likely serve similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative futures tools. It only lists valid exchange codes and the return type, with no context about use cases, prerequisites, or exclusion of sibling tools. The schema default for 'symbol' (cffex) is mentioned in the schema but not explained in the description.
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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds value by including the source URL (endata.com.cn) and the behavioral constraint that the returned data is for the day before the specified date. However, it does not disclose pagination, rate limits, or the exact output structure beyond stating it returns a pandas DataFrame.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title line, a URL, and short param/return docstrings. It is not verbose, but the return line '影票房-影院票房-日票房排行' is largely redundant with the title, which slightly detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, but the description is incomplete for real-world use. It does not explain the columns of the returned DataFrame, specify the date format, or clarify whether the ranking covers all cinemas or a specific subset. The note about the previous day's data is present, but critical details for invoking the tool correctly are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden of explaining the 'date' parameter. It provides a Chinese explanation that the date refers to the previous day's box office data, giving semantic meaning beyond the bare schema. However, it fails to specify the required format (e.g., YYYYMMDD) or clarify that the parameter is optional despite having a default value, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '电影票房-影院票房-日票房排行' (Movie Box Office - Cinema Box Office - Daily Ranking), which clearly identifies the tool's function as retrieving daily cinema box office rankings. It distinguishes from siblings like movie_boxoffice_daily and movie_boxoffice_cinema_weekly by specifying 'cinema' and 'daily' in the title. However, it lacks an explicit verb, relying on a noun phrase fragment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the resource name and date parameter, but does not explicitly state when to use this tool versus alternatives. It does provide a usage hint by noting the date parameter represents '当前日期前一日的票房数据' (box office data of the day before the current date), which tells users about data availability, but no exclusions or alternative tool references are given.
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 already indicate read-only, idempotent, and non-destructive behavior. The description adds the data source URL and return type (pandas.DataFrame), which is valuable, but it doesn't disclose data freshness, possible delays, or how the data is scoped. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, containing only the title, source URL, return data description, and return type. It's efficient, though slightly fragmentary due to the `:return:` style instead of a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description should explain what the returned DataFrame contains, but it only says '实时票房数据' (realtime box office data) without listing columns or data granularity. However, it's a simple zero-parameter read-only tool, and the name and URL provide context, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the baseline per rubric is 4. The description adds nothing parameter-related, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns real-time box office data (实时票房数据) and points to the source URL, which clearly identifies the tool's purpose. It distinguishes from siblings like movie_boxoffice_daily by the 'realtime' qualifier, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many other movie box office tools (daily, weekly, monthly, etc.). There is no mention of alternatives, prerequisites, or caveats about data availability.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame) but no additional behavioral caveats such as data freshness, pagination, or parameter-dependent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core statement, followed by URL and parameter documentation. It is reasonably concise with no filler, though the inclusion of the URL and return type adds a bit of clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters, but the description does not explain the output columns, the effect of the contract parameter, or whether it returns all contracts or filters by symbol/contract. It also fails to differentiate from sibling tools, leaving ambiguity for an agent trying to choose the right option tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by listing the exact allowed symbol choices (e.g., 豆粕期权, 玉米期权) and providing a contract example ('au2012'). It does not define the contract code format fully or explain what happens when parameters are omitted, but it adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides all current option contracts (calls and puts) as real-time market quotes from Sina. However, it does not differentiate from the similarly named sibling tool option_commodity_contract_sina, so the purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative option-related tools among the many siblings. No exclusions, alternatives, or contextual triggers 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the data source URL and specifies the return is a pandas DataFrame, plus the symbol is a call option contract field. However, it does not describe pagination, date ranges, or column structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with title, URL, param, and return docs. It repeats the title in the return line, which is slightly redundant, but overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, basic invocation guidance is covered. However, with no output schema, the return is only described as '合约历史行情-日频' without column details or any caveats, leaving some ambiguity for the agent about the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description carries the burden. It explains the symbol should be the call option contract field returned by option_sina_option_commodity_contract_list and gives an example default 'au2012C392', providing meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '合约历史行情-日频' (contract historical quotes - daily frequency) and provides a Sina URL, but lacks a verb like 'get' or 'retrieve'. The tool name clarifies it is for commodity options, but the description does not distinguish from sibling tools such as option_hist_czce or option_sse_daily_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The param doc hints that the symbol should come from option_sina_option_commodity_contract_list, which is an implied dependency, but there is no explicit when-to-use or alternative guidance. No sibling comparisons 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds the return type (DataFrame) and a source URL, which is useful, but it does not disclose any other behavioral traits such as data scope, update frequency, or error behavior. It adds some value beyond annotations but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear source URL and return type. However, it begins with the same phrase as the annotation title, creating minor redundancy. Overall, it is appropriately sized but not perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimal. It states that option contract information is returned as a DataFrame but does not describe the columns, the range of contracts (e.g., all exchanges, all maturities), or any other details. This leaves the agent uncertain about the data's structure and coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema coverage is 100%, so there are no parameter details to explain. The description does not add parameter semantics, but none are needed. The return type documentation is a slight bonus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an openctp interface for option contract information and states that it returns a pandas DataFrame. It provides a specific resource ('期权合约' option contracts) but lacks an explicit action verb like 'list' or 'get', and does not differentiate it from sibling option 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/5Does 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, nor any exclusions or preferred use cases. The agent must infer usage solely from the tool name and minimal description.
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 already declare the tool safe (readOnly, idempotent). The description adds the return type (pandas.DataFrame) and the source URL, but doesn't disclose date format expectations, data coverage limits, or any other behavioral nuances beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with docstring tags and a clear layout. The symbol list is lengthy but necessary. The URL adds useful context without excessive fluff, though it could be omitted given the title already conveys the source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only retrieval, the description is mostly complete: it identifies the data source, returns a DataFrame, and lists valid symbols. It lacks a date format note, any warning about data availability, and explicit guidance on when to use this versus similar exchange-specific tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description carries the full burden for parameters. It lists all valid symbols, specifies types, and names each parameter's meaning. However, it does not specify the trade_date format (e.g., YYYYMMDD), relying on the schema default as an implicit example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this provides daily-frequency option market data for the Dalian Commodity Exchange, distinguishing it from sibling tools for other exchanges. Though it's phrased as a label rather than a verb phrase, the return type and parameters make the purpose 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/5Does 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. Sibling tools for other exchanges (e.g., option_hist_czce, option_hist_shfe) are not mentioned, and no exclusions or preferred contexts 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: the note '注意品种的上市时间' warns that data may not exist before a product's listing date, and it specifies the return type as pandas.DataFrame with daily frequency. However, it does not describe error handling, rate limits, or what happens for invalid inputs beyond that caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a raw docstring with a category path, a URL, parameter definitions, and return info. It is not overly long but includes some redundancy (the category path duplicates the annotation title) and the URL adds little value. The structure is conventional and readable, but could be tightened and front-loaded with a clear purpose sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter historical data download tool, the description is largely complete: it specifies the data source (CZCE), the parameters (symbol and year), the frequency (daily), and the return type (DataFrame). It lacks a list of DataFrame columns and does not clarify the symbol input format, but these are not critical gaps for a tool of this complexity, especially given the read-only annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It thoroughly documents the symbol parameter with a complete mapping of Chinese names to codes (白糖→SR, etc.) and explains year with the listing-time caveat. However, there is a potential ambiguity: the default value for symbol is 'SR' (a code), while the mapping is keyed by Chinese names, so it is unclear whether the parameter expects the Chinese name or the code. This prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (CZCE options historical data) and the return statement '指定年份的日频期权数据' clarifies it returns daily options data for a specified year. However, it lacks an explicit verb like 'get' or 'download' in a standalone sentence, relying on the breadcrumb title '期权历史行情下载' and the tool name. It distinguishes from sibling option_hist_czce only through the 'yearly' in the name, not through explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling option_hist_* tools (e.g., option_hist_czce, option_hist_dce). The description does not mention alternatives, exclusions, or prerequisites. The year parameter and return type imply yearly historical data, but this is not explicitly stated as a usage condition.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that the tool queries a specific Eastmoney endpoint and returns a pandas.DataFrame, which is consistent with annotations. However, it does not disclose potential rate limits, pagination, or date coverage limitations, so it provides only minimal behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a clear header line, URL, parameter definitions, and return type. It is scannable and not excessively long, though it redundantly repeats type information already present in the schema (e.g., ':type symbol: str'). The overall structure aids readability, and every line serves a purpose in defining the tool's interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should have explained the structure of the returned DataFrame (e.g., columns, index) or what the dragon-tiger list contains. It gives the source URL and parameter choices but leaves the return format implicit. For a data retrieval tool, this is a noticeable gap, although the parameter documentation provides useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It provides explicit choice lists for symbol ('510050', '510300', '159919') and indicator (four specific Chinese option metrics), and describes trade_date as '交易日期' (trading date). The default value '20220121' implies YYYYMMDD format. All three parameters are meaningfully documented, significantly compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the Eastmoney data center's option dragon-tiger list, citing the exact URL and naming the resource '期权龙虎榜单'. It specifies three parameters and a DataFrame return, making it distinguishable from other option-related tools in the sibling list (e.g., option_premium_analysis_em). However, it lacks an explicit verb like 'retrieve' or 'fetch', relying on context and the return type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the data source and parameters, without mentioning which other tools might be more appropriate for other option data needs (e.g., option_current_em for real-time quotes). No exclusions or contextual triggers are given, leaving the agent to infer usage solely from the name and URL.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), which is useful but does not disclose other behavioral aspects like pagination, freshness, or data scope. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and each part serves a purpose: the title identifies the content, the URL gives the source, and the return annotation states the output type. There is no wasted text, though the content is sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple data retrieval task, the description is minimally adequate: it names the dataset, provides a source URL, and states the return type. However, it does not elaborate on the DataFrame's columns or the meaning of '折溢价', and lacks context on how this differs from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description correctly implies no parameters are needed. Since there are no parameters to document, the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '期权折溢价' (option premium/discount) from East Money's data center, with a source URL. It names the specific data set and implies retrieval via the return type, but lacks an explicit action verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many similar option-related sibling tools (e.g., option_value_analysis_em, option_risk_analysis_em). There is no mention of alternatives or specific use cases.
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 already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that the return is a tuple of two lists (call/put codes) and clarifies parameter semantics. However, it does not disclose potential edge cases (e.g., empty lists), the format of the codes, or data source-specific behaviors, which would add further 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear header and structured param/return lines. It is free of fluff and front-loaded with the purpose. A brief usage example would be the only improvement, but the current structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with 3 parameters and no output schema, the description covers the essential inputs and output type (Tuple[List, List]). However, it omits details like the format of returned codes, what happens if no data matches, and any timezone or data update specifics. Given the annotations cover safety, the description 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does so well: 'symbol' lists allowed choices ('看涨期权'/'看跌期权'), 'trade_date' is explained as expiration month with example '202002', and 'underlying' gives concrete tickers (510050, 510300). This adds meaning beyond the bare schema properties and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '上海证券交易所-所有看涨和看跌合约的代码', clearly indicating the tool returns option contract codes for the Shanghai Stock Exchange. The resource (option codes) and scope (all call/put contracts) are explicit, though an action verb like 'get' or 'list' is missing. It does not directly distinguish itself from sibling tools such as option_sse_list_sina, but the focus on 'codes' makes it fairly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No exclusions, prerequisites, or scenarios are mentioned. The description only lists parameters and return type, leaving the agent without context for choosing this tool over similar option-related siblings.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety traits. The description adds the return type (pandas.DataFrame) and scope of data (all daily historical data), which is useful context beyond the annotations. No contradiction exists, but details like data source, potential delays, or symbol format requirements are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary followed by a param and return docstring. Every line serves a purpose with no redundancy. It is front-loaded with the main description and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description is minimally adequate. However, it lacks details about the output DataFrame columns, how to obtain valid symbol codes, and the data source (Sina). With no output schema and many sibling tools, the absence of symbol format or data source context leaves gaps for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the lone parameter 'symbol', but the description's docstring provides a basic meaning: '期权代码' (option code). This adds some value beyond the schema, though it lacks format specifics (e.g., examples, string length, or how to find valid codes). The default value '10003889' in the schema offers a clue but not sufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides daily frequency data for a specified option ('指定期权的日频率数据') and returns all daily historical data. It distinguishes from sibling tools like option_sse_minute_sina (minute data) and option_sse_spot_price_sina (spot data), though it doesn't explicitly name alternatives. The verb is implied as 'retrieve' or 'get', making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other option-related tools. There is no mention of alternatives, prerequisites, or context for choosing daily data over minute or spot data. The description only implies usage by stating the parameter, but lacks explicit selection criteria.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame) but does not disclose other behavioral traits like rate limits, pagination, or the exact content of the returned data beyond the generic '日频行情数据'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and well-structured: a brief title, source URL, and clear parameter/return documentation. It front-loads the key purpose. However, it repeats the title already present in the annotations, which is a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the returned DataFrame contains (columns like open, high, low, close, volume, open interest). It only says 'daily market data', which is sufficient for high-level selection but incomplete for understanding the exact data shape. The parameter and safety context are adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by listing all valid symbol choices (e.g., 铝期权, 铜期权) and explaining that trade_date is a trading day. It adds meaning beyond the bare property names and defaults, though it does not specify the date format (implied by the default '20250418').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides Shanghai Futures Exchange option daily market data, with a specific resource (SHFE options) and frequency (daily). It is distinct from siblings like option_vol_gfex (GFEX) and option_hist_shfe, though it lacks an explicit verb such as 'get' or 'fetch', relying on the noun phrase '日频行情数据'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not specify when this option data source is preferred, nor does it exclude cases or mention sibling tools that might be more appropriate. The description only states what data it returns, not how to choose it.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that the return type is a pandas DataFrame and the data source URL, which is minor but not contradictory. No information about data delays, pagination, or limits is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but the first line repeats the annotation title exactly, adding no new information. The URL and return type are useful, so it is not overly bloated, but the redundancy slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only tool with good annotations, the description provides the scope (Shanghai/Shenzhen), source (Eastmoney), and return type (DataFrame). It is sufficiently complete for basic usage, though it could mention the sibling historical tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema has 100% coverage, so the description need not explain parameters. Baseline 4 applies for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns 沪深 REITs-实时行情 (Shanghai/Shenzhen REITs real-time quotes), giving a clear verb and scope. It implicitly differentiates from historical REITs tools like reits_hist_em by specifying '实时行情', though it doesn't name 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/5Does 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 reits_hist_em or reits_hist_min_em. The description lacks any context about typical use cases, exclusions, or recommended alternatives.
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 already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose additional behavioral details such as data freshness, column structure, or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with title, source URL, parameter documentation, and return type. It is somewhat redundant (title and return phrase largely repeat) but still information-dense and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and read-only annotations, the description is reasonably complete. However, it does not describe the DataFrame columns, date range, or frequency of the historical data, and there is no output schema to fill this gap. The lack of distinction from the similar sibling 'repo_rate_hist' also leaves ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description or enum for the 'symbol' parameter, but the description explicitly lists the allowed values: {'回购定盘利率', '银银间回购定盘利率'}. This is essential information beyond the schema and largely compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing historical repo fixing rate data from the China Foreign Exchange Trade System, with a source URL. It is specific to the resource, though it lacks an explicit verb and does not distinguish from the sibling tool 'repo_rate_hist'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 implies usage through the parameter choices but does not state exclusions or mention the similar sibling tool 'repo_rate_hist'.
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 already declare readOnly=true and destructive=false, so the safety profile is covered. The description adds context about data cleaning/formatting and the returned DataFrame structure (Date, Open, High, Low, Close), which is useful but does not disclose rate limits, error behaviors, or data coverage nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a leading sentence followed by a URL and docstring-style param/return sections. The URL is extraneous, but the core content is front-loaded and each section serves a purpose. It is slightly verbose but remains readable and efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential semantics: data source, processing, parameters, and return format. However, it lacks differentiation from sibling tools like futures_zh_minute_sina, does not mention data range or pagination, and provides no output schema, leaving some ambiguity for an agent deciding between this and related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage), so the description carries the full burden. It explains the symbol format with an example (IF2008 for 沪深300 futures August 2020) and lists allowed period values {'1','5','15','30','60'} minutes, adding meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches minute-level historical futures data from Sina Finance and performs data cleaning/formatting. It specifies the source, data type, and processing step, which distinguishes it from raw retrieval tools like futures_zh_minute_sina, 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 Guidelines2/5Does 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 does not mention prerequisites, such as which futures contracts are supported or when the minute-level data would be preferred over daily or real-time data, leaving the agent without explicit usage context.
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 already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose any other behavioral traits like data freshness, rate limits, or error conditions, so it only partially complements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and directly lists the resource, URL, and return type without redundant text. The structure is functional, though it reads more like a label than a sentence, and it omits an explicit action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool, the description provides essential information (resource, source, return type), but it lacks details about the DataFrame's columns, time range, or any caveats that might affect usage. 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the empty schema fully covers parameter semantics—there is nothing to document. The baseline of 4 applies since no parameter ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (全国三元仔猪 - national three-way piglets) and the data source URL, making the tool's purpose understandable. However, it lacks an explicit verb like 'get' or 'fetch' and does not differentiate from sibling hog price tools in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 spot_hog_crossbred_soozhu or spot_hog_soozhu. The description only states the resource and return type without any 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the data source URL, which is useful context. However, it does not disclose other behavioral traits such as update frequency, data volume, or access constraints, which would be valuable for a no-parameter 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title, a source URL, and a return type. It is not bloated, but the URL may be of limited value to an AI agent, and the content is somewhat repetitive (title repeated in the return line). Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), and the description states the data metric and return type. However, it does not explain columns, update periodicity, or the exact meaning of 'half-month trend', leaving some ambiguity about the resulting DataFrame structure. Adequate but with gaps for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema description coverage is trivially 100%. The description does not need to explain parameters. The baseline for no-parameter tools is 4, and the description appropriately focuses on the return value rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: '全国育肥猪合料（含自配料）半月走势' (national fattening pig mixed feed including self-mixed, half-month trend). It is distinct from sibling soozhu tools by the specific commodity (feed vs. hogs, corn, etc.), though it does not explicitly contrast with them. The verb is implied via the return annotation, making the purpose understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other soozhu-related tools, nor any exclusions or prerequisites. The description only states what it returns, leaving the agent to infer usage context from the name and siblings.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds a source URL and return type (pandas.DataFrame), which offers some behavioral context, but it does not mention network behavior, rate limits, or data freshness beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first line repeats the title annotation verbatim. The remaining lines (URL, return, rtype) are useful, but the duplicate title wastes some space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately explains that the output is a DataFrame containing an exchange-and-product mapping table. It also provides the source URL for verification. This is sufficient for selecting and invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the input schema fully covers all invocation needs. The description need not add parameter explanations; the baseline score for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns a mapping table of exchanges and product varieties from the 99qh.com website. It provides a clear resource and expected output, though it lacks an explicit action verb (e.g., 'fetch', 'scrape') and does not differentiate from sibling tools like spot_price_qh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as spot_price_qh or futures_spot_price_previous. It only describes the output and source, without any contextual or exclusionary information.
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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a source URL and states the return type (pandas.DataFrame), but does not disclose any data range, pagination, or limitation details. It adds some value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title, then provides URL, param doc, and return type. Each line serves a purpose, though the return line partially repeats the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description gives the essential info (source, param, return type). However, it lacks details about data coverage (e.g., A-shares only, range of report periods) that would help an agent fully understand the output. The good annotations mitigate some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the 'symbol' parameter as '股票代码; 带市场标识' (stock code with market identifier), and the URL example 'sh600519' clarifies the expected format. This goes beyond the schema's minimal type/default definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as Eastmoney's balance sheet by report period, and the 'by_report_em' naming distinguishes it from sibling tools like stock_balance_sheet_by_yearly_em. However, it lacks an explicit verb like 'get' or 'retrieve', functioning more as a title than a directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_balance_sheet_by_yearly_em or stock_balance_sheet_by_report_delisted_em. It only states what it returns, but no selection criteria.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the return type (pandas.DataFrame) and the specific source URL, but does not disclose data coverage, date ranges, or potential delays. Overall, it adds minor behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and direct, but the URL line adds bulk without much functional benefit. It is front-loaded with the purpose. The param/return structure is a standard docstring format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks information about the DataFrame's columns or the range of yearly data returned. The absence of an output schema makes this a real gap for the agent to interpret results. Still, the core purpose and parameter are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists only 'symbol' with no description. The description adds a key semantic detail: the symbol must include the market identifier (带市场标识), which clarifies format like SH600036. This helps the agent construct a valid argument, but it does not provide examples or case-sensitivity rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the balance sheet (资产负债表) for stocks, scoped to yearly (按年度), and references East Money as the data source. While it lacks an explicit verb like 'get' or 'query', the combination of name and description makes the function clear. It is distinguishable from siblings like stock_cash_flow_sheet_by_yearly_em by the statement type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this is for annual reports only, nor contrast with quarterly or report-based balance sheet tools. The reference URL is a data source link, not usage guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which establish the safety profile. The description adds the return type (pandas.DataFrame) and the concrete data source URL, but does not disclose any other behavior such as possible missing data, refresh delays, or what happens for invalid sector names. This is acceptable but minimal given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose line, then a URL and parameter definitions. It is tight and free of fluff, though the inclusion of a raw URL might be seen as non-essential for an automated agent. Overall, it earns its place in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description is incomplete. It fails to mention the available time range, data granularity (e.g., 1-minute against which trading sessions), or any example usage. It also lacks a pointer to companion tools for obtaining sector symbols (e.g., stock_board_industry_name_em), which are critical for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description carries the burden. It does explain symbol as '板块名称' (sector name) and period as allowed choices {'1','5','15','30','60'}, which provides crucial meaning. However, it does not specify exact expected format (e.g., Chinese sector names only) or how to discover valid symbols, leaving the agent partially informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (Eastmoney industry boards) and action (retrieve minute-level historical quotes) with the exact data source URL. The term '分时历史行情' explicitly distinguishes this from same-sector daily history (stock_board_industry_hist_em) and spot data (stock_board_industry_spot_em) siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only lists parameters and the return type, with no mention of trade-offs, prerequisites (e.g., obtaining sector names via name-list tools), or exclusions. This leaves the agent to infer usage solely from the name.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal context by giving the source URL and return type (pandas.DataFrame), but does not disclose any behavioral traits such as data update frequency, return size, or whether network access is required. This is acceptable given the simple nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact, containing only the tool title, URL, and return type in a structured docstring-like layout. It is front-loaded with the most important information, though the formatting is a bit odd with mixed Chinese and technical tokens. It is appropriately sized for a no-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, read-only, simple return), the description is nearly adequate. It states the data source and return type, but does not specify what the DataFrame contains (e.g., time series, columns, historical vs. current). An agent would need external knowledge of the Buffett Indicator to fully understand the output. This is a minor gap for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input space. According to the rubric, 0 parameters yields a baseline of 4. The description does not need to add parameter information since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the 巴菲特指标 (Buffett Indicator) and provides the source URL. It uses an implied 'return' verb, and the tool name itself is explicit. However, it does not explain what the Buffett Indicator is or distinguish it from other valuation indicators, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 intended use cases, prerequisites, or exclusions. The description only gives a URL and return type, so the agent receives no decision-making support.
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 already declare readOnlyHint=true and destructiveHint=false, providing the core safety profile. The description adds that the tool returns a pandas.DataFrame, which is useful behavioral context beyond annotations, but does not disclose other traits like data source specifics, rate limits, or edge cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a docstring-style block with a title, source URL, param definition, and return type. It is compact and front-loaded with the purpose, though the long URL is arguably extraneous for tool invocation. Overall, each element earns its place and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, annotations present), and the description covers the parameter meaning and return type. However, it does not explain supported market identifier formats beyond the example, nor the content structure of the cash flow statement beyond 'annual'. This is adequate for basic retrieval but leaves gaps for edge cases and expected data shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (symbol) with 0% description coverage. The description explicitly defines symbol as '股票代码; 带市场标识' (stock code with market identifier), adding crucial format context beyond the schema's default value, thus compensating well for the lack of schema-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides '现金流量表-按年度' (cash flow statement by annual) for stocks, which clearly identifies the resource and period granularity. It distinguishes from siblings like stock_cash_flow_sheet_by_quarterly_em by the '按年度' (annual) qualifier, though it lacks an explicit verb like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as stock_cash_flow_sheet_by_quarterly_em or stock_cash_flow_sheet_by_report_em. It merely states its name and parameter/return, leaving the agent to infer usage context without explicit exclusions or alternatives.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side-effect posture. The description adds the pandas.DataFrame return type and the source URL, giving some context beyond annotations, but it does not disclose potential latency, data freshness, pagination, or how the date range affects results. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring of about 10 short lines, front-loading the data source and URL. It avoids fluff, presents parameters in a clear list, and gives return type. It earns a high score for efficiency, though it could be slightly more narrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters, strong annotations, and no output schema. The description provides the source URL, param semantics, and return type, which is sufficient for a basic invocation. However, the return value is only labeled as '对外担保' without describing columns, rows, or behavior across market segments, and date format is not explicit. This is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates for parameter meaning. It explains 'symbol' with a specific choice list (全部, 深市主板, etc.) and defines start_date and end_date as '开始统计时间' and '结束统计时间'. However, it does not specify the date format (e.g., YYYYMMDD) beyond the defaults, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves external guarantee (对外担保) data from CNInfo's data center, with the first line naming the specific thematic statistics category. The tool name and param descriptions reinforce this, but there is no explicit verb phrase like 'Fetch' or 'Get' and no direct comparison to sibling 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/5Does 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 related tools like stock_cg_equity_mortgage_cninfo or stock_cg_lawsuit_cninfo, nor does it define the appropriate use case beyond the raw parameter descriptions. The URL is given, but no selection criteria or exclusions are stated.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the data source URL, but does not disclose behavioral details such as network dependency, potential website changes, or response format caveats. This does not contradict annotations, but adds limited value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear sections (source, URL, param, return, rtype). The first line repeats the title already present in the annotations, which is mildly redundant, but overall the description is efficiently structured and front-loaded with the key identity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description covers the essential parameter and return type, but lacks detail about the DataFrame columns, index, or the nature of the data (e.g., historical vs current). There is no output schema to compensate, so the description should provide more context about what the returned data represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage, but the description compensates by documenting the sole parameter: ':param symbol: 股票代码' with type str. This gives meaningful semantics beyond the bare schema. It could be more precise about the expected format (e.g., 6-digit code, leading zeros), but the default value '600000' provides a concrete example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (东方财富网), the specific data category (主力控盘-机构参与度), and the return type, making it clear this tool retrieves institutional participation data for a stock. However, it lacks an explicit action verb like 'get' or 'fetch', and does not directly differentiate itself from sibling tools beyond the feature name in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_comment_detail_scrd_desire_em or stock_comment_em. The description only provides the source URL and parameter documentation, leaving the agent to infer usage context from the tool name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is lower. It adds the source URL and return type (pandas.DataFrame) but does not disclose potential rate limits, error behavior, or whether the symbol parameter expects a market prefix (despite the URL example 'sz000001'). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring format with source URL, parameter definitions, and return type. Every line contributes useful information, though it could be improved by front-loading a one-sentence summary before the technical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description's 'return: 筹码分布' is the only return value documentation, lacking column details or behavior for invalid inputs. It covers basic invocation (symbol, adjust) but leaves gaps in data semantics and edge cases, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by defining both parameters: 'symbol' as stock code and 'adjust' with explicit choices ('qfq', 'hfq', ''). This adds meaningful value over the bare schema, though the exact format for 'symbol' (e.g., 6-digit code vs. with prefix) remains ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing chip distribution (筹码分布) for concept boards in the Eastmoney daily K-line market center, with a source URL and parameter documentation. It clearly names the resource and scope, though it lacks an explicit verb like '获取' or 'query' to indicate an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_board_concept_hist_em or stock_zh_a_hist. There is no mention of prerequisites, market prefixes, or typical use cases; the description only documents parameters without selection criteria.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the return type (pandas.DataFrame) and the source URL, but does not disclose any further behavioral traits such as data scope, update frequency, or whether the result is a full dataset. This adds some context but remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a title-like line, a URL, and return type. It is front-loaded and efficient, though the first line repeats the annotation title. It earns its place but could be more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with strong annotations, this is minimally adequate. It provides the source and return type but does not explain what the DataFrame contains (e.g., columns, per-stock vs aggregate data). Given the simplicity, it meets the baseline but lacks richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not elaborate on parameter semantics. Baseline for 0 params is 4. The empty schema already provides full coverage, and the description adds nothing extra, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Refinitiv ESG ratings from Sina Finance's ESG Rating Center, with a direct URL and return type. This distinguishes it from sibling ESG tools like stock_esg_msci_sina and stock_esg_hz_sina. However, it lacks an explicit verb like 'get' or 'return', relying on the docstring-style format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other ESG rating providers, nor does it provide context on selection criteria. With multiple ESG sibling tools, this gap makes it harder for an agent to choose correctly.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the source URL, but no additional behavioral context such as data freshness, potential rate limits, or output structure. It is not misleading, but it adds minimal transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, containing only the title line, a URL, and return docs. There is no fluff or redundant text. However, it is formatted as a raw docstring rather than a clear natural-language sentence, which is slightly less agent-friendly than a well-phrased statement. Still, it is efficient and every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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) and lack of an output schema, the description provides only minimal information: the source and the return type. It does not describe what the DataFrame contains (columns, rows, or meaning of the data), which is a notable gap for an agent that needs to interpret results. The URL helps, but the return spec is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline for 0 parameters is 4, and the description does not need to compensate for missing schema information. The :return: and :rtype: docstring lines are about output, not parameters, so this dimension is appropriately scored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Sina Finance ESG Rating Center, Zhidin rating. It also specifies the source URL and return type. Although it lacks an explicit verb like 'retrieve' or 'get', the tool name and zero-parameter schema imply a data-fetching operation, and it distinguishes from sibling ESG tools by naming the rating provider (秩鼎).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the sibling ESG tools (e.g., stock_esg_hz_sina, stock_esg_msci_sina). The description only names the data source and provides a URL; it does not state any context, prerequisites, or alternatives. An agent would have to infer usage from the tool name alone.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. Description adds the source URL and return type (pandas.DataFrame). It doesn't add behavioral context like rate limits or pagination, but annotations cover the most important operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and contains essential elements: source, section, URL example, parameter definition, return type. It's structured like a typical docstring with clear labels. Could be slightly more readable but every line is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter (default given), a clear return type, and strong annotations, the core usage is covered. However, no mention of what the returned DataFrame contains (columns, indices) or whether the default symbol is meaningful. The URL example is helpful but the tool's overall scope (dividend details) is only loosely described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of the parameter. The description explains that symbol is a 股票代码 (stock code) and provides an example '300073' in the URL, adding meaning beyond the bare schema. This is sufficient for a single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: retrieving 分红送配详情 (dividend/distribution details) from 东方财富网's data center for a given stock code. The title and description align, and the specific URL example clarifies the resource. It does not explicitly differentiate from sibling tools like stock_fhps_em or stock_fhps_detail_ths, but the target (东财 detail page) is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid stock code) or contrast with sibling tools like stock_fhps_detail_ths (THS version) or stock_fhps_em (list). The only usage hint is the parameter needing a stock code, which 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds the data source URL and return type (DataFrame) but doesn't disclose edge cases, error behavior, or data fields. It adequately communicates a safe read operation without adding significant new behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, uses clear docstring conventions, and has no wasted words. It front-loads the purpose and includes essential parameter and return info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description covers the basic purpose, parameter, and return type. However, it doesn't describe the expected DataFrame columns or the meaning of '分红融资' beyond a generic term, and lacks usage context compared to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with no description, but the description documents it as '股票代码' (stock code) with type str, and gives an example URL. This fills the gap partially, but lacks format details or exchange prefix guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '同花顺-分红情况' and includes a URL to a bonus page, plus a return type of DataFrame, indicating it retrieves dividend/financing data for a given stock from Tonghuashun. It doesn't explicitly contrast with sibling tools like stock_fhps_detail_em, but the name and source are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. There are multiple dividend-related sibling tools (stock_fhps_em, stock_history_dividend, etc.) but the description offers no criteria for selecting this specific tool, nor 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?
The annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds that the return type is pandas.DataFrame, which is useful, but it doesn't disclose any additional behavioral traits such as date format restrictions, pagination, or live website scraping. Minimal extra transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a docstring structure with a title, source URL, and parameter/return documentation. Every line serves a purpose with no extraneous text, though the phrasing is terse and lacks a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the source, parameter meaning, and return type. However, it omits details about the DataFrame's columns, the scope (e.g., all A-shares), and any date range limitations. Without an output schema, more detail would be expected for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and default with no description (0% coverage). The description compensates by explaining that 'date' refers to the 分红送配报告期 (dividend distribution report period), clarifying its meaning and format implied by the default. This adds meaningful semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving dividend/distribution data from East Money's Data Center, as seen in the title and URL. It states a return type of pandas.DataFrame, implying a data retrieval action. However, it lacks an explicit verb and doesn't differentiate from similar sibling tools like stock_fhps_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides a parameter and return type, with no context about use cases, prerequisites, or alternative tools. This is a significant gap given the many dividend-related sibling 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type, but no additional behavioral traits such as rate limits, data scope, or potential side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with title, URL, parameter descriptions, and return type. Each section provides useful information without redundancy, though the URL could be considered optional for the agent's invocation logic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should have explained what columns or specific indicators are returned in the DataFrame, but it only mentions the return type. It also does not clarify what 'new' means relative to other THS financial abstract tools, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the schema by explaining symbol as '股票代码' and indicator as '指标', and by listing the exact allowed values for indicator: {"按报告期", "一季度", "二季度", "三季度", "四季度", "按年度"}. This significantly aids the agent in parameter selection, although it does not specify the exact format for symbol (e.g., 6-digit code).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '同花顺-财务指标-重要指标' and the return type '同花顺-财务指标-主要指标', clearly indicating it retrieves important financial indicators from THS for a given stock. However, it lacks an explicit verb like 'get' or 'retrieve', and does not distinguish itself from sibling tools such as stock_financial_abstract or stock_financial_abstract_ths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists parameters and return type, with no mention of scenarios, prerequisites, or exclusions, leaving the agent without decision support.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a source URL and specifies the return type (pandas.DataFrame), but provides no further behavioral details such as data freshness, pagination, or error conditions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with title, URL, parameters, and return type. It is front-loaded with the title and source, and each section is relevant. The return line repeats the title but is not excessive. It is concise and well-organized for an API docstring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params) and annotations cover safety, but there is no output schema and the description does not explain the structure or columns of the returned DataFrame. The source URL provides a reference, and the indicator choices hint at data granularity, but an agent may lack clear knowledge of what data rows/columns to expect, especially given the large number of sibling financial data tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions or enums, and schema coverage is 0%. The description compensates by defining symbol as 股票代码 (stock code) and enumerating the exact allowed values for indicator: "按报告期", "按年度", "按单季度". This adds significant meaning beyond the bare parameter names, though it does not explain the format of the symbol or the semantics of each indicator value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states this fetches 同花顺-财务指标-主要指标 (THS financial main indicators) for a given stock symbol, with a source URL. It clearly identifies the resource and source, though it lacks an explicit action verb like 'get' or 'fetch'. It is distinguishable from siblings by the 'ths' suffix and '主要指标' qualifier, but does not explicitly differentiate from similar tools like stock_financial_abstract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_financial_abstract or stock_financial_abstract_new_ths. The description only lists parameters and return type, with no context about use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the data source URL and return type (pandas DataFrame) but discloses no rate limits, pagination, or formatting nuances. This is acceptable for a read-only tool but contributes only modest behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a clear docstring format with a title, URL, parameter entries, and return type. It is reasonably concise without unnecessary fluff, though the :return: line duplicates the title. The structure makes the information easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description would benefit from explaining the DataFrame's structure, such as row content or key columns. It does provide the source URL, parameter semantics, and safety annotations, but lacks details on return value composition or edge cases. For a straightforward report retrieval tool, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero property descriptions, so the description compensates by explaining each parameter: stock (股票代码), symbol (choice of three statement types), and indicator (choice of annual/quarterly periods). It also lists the allowed values for symbol and indicator, which is valuable. It lacks further elaboration on value meanings or examples, but the provided labels are sufficient for domain-aware users.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a source for US stock financial reports (三大报表) from East Money, supported by the URL and title. It distinguishes from siblings that cover A-share or HK financials by specifying '美股'. However, it lacks an explicit action verb like 'fetch' or 'get', though the intent 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/5Does 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, nor does it mention prerequisites, exclusions, or specific use cases. It simply lists parameters and return type, leaving tool selection reasoning entirely to the agent.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful context by specifying the return type (pandas.DataFrame) and the data source URL, but it does not disclose details like data freshness, pagination, or column specifics, which would be valuable for a financial 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the tool's purpose. It includes a URL for reference and a compact docstring, but the layout is a bit unstructured (mixing Chinese title, URL, and parameter notes). Still, every line serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description specifies the return type (DataFrame) and the general content (top 10 floating shareholders), but lacks details on columns, index, or any peculiarities of the data. Given the simple one-parameter interface and good annotations, this is adequate but not rich. The lack of an output schema increases the need for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and default value, but the description's docstring ('报告期' for date) adds semantic meaning, clarifying it is the reporting period. With only one parameter and 0% schema description coverage, the description adequately compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (东方财富网-数据中心-股东分析-股东持股明细) and the specific data (十大流通股东), making the tool's purpose unambiguous. It distinguishes itself from sibling tools by naming the exact category of shareholders, though it doesn't explicitly compare to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many similar sibling tools (e.g., stock_gdfx_free_holding_analyse_em, stock_gdfx_holding_detail_em). The description gives the data source URL and parameter docstring but omits context like typical use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source (East Money URL) and the return type (pandas.DataFrame), but does not disclose data lineage, column contents, or any potential quirks like pagination or historical coverage. It provides context beyond annotations but not rich behavioral detail, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring of four lines: a title, a reference URL, two parameter explanations, and return type. It is front-loaded with the title, each section is clearly labeled, and there is no extraneous prose. The URL duplicates the title but serves as a citation. This is a model of concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters and no output schema. The description provides the return type and param meanings, but leaves gaps: it does not describe the DataFrame columns, distinguish free/circulating shareholder data from other shareholder data, or explain how to choose this over the many sibling gdfx tools. Given the annotation safety coverage, it is adequate for a basic read operation but lacks context for nuanced selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only default values with no descriptions (0% schema coverage). The description supplements this with ':param symbol: 带市场标识的股票代码' and ':param date: 报告期', clarifying that symbol requires a market prefix and date is the reporting period. This adds meaning, but the explanations are terse and do not specify exact formats (e.g., YYYYMMDD) beyond the defaults, so it does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's title and first line state '东方财富网-个股-十大流通股东' (East Money individual stock top 10 circulating shareholders), and the URL points to the detailed shareholder research page. The ':return:' field states it returns 十大股东 as a DataFrame, making the purpose clear. However, there is no explicit verb like 'get' or 'retrieve', and it does not explicitly differentiate from sibling tools like stock_gdfx_top_10_em in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. It does not mention any preconditions, typical use cases, or exclusions. The only contextual clue is the URL example for symbol SH688686, which implies usage but does not state when to select this over similar gdfx 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read-only operation. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose any additional behavioral aspects such as pagination, rate limits, or error handling. This adds some context but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear structure: source title, URL, parameter definitions, and return type. Every line serves a purpose without unnecessary fluff. It is appropriately sized for a parameterized data-fetching tool, though it could be slightly more concise by omitting the redundant title line that repeats the annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core aspects: data source, parameters, and return type. However, it lacks detail about the returned DataFrame's columns, any prerequisite knowledge (e.g., how to format the date beyond the default), and does not place the tool in context relative to sibling tools. For a simple data-fetching tool with no output schema, this is adequate but with clear gaps in usability guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: 'date' as report period, 'indicator' as shareholder type with explicit choices (个人, 基金, QFII, 社保, 券商, 信托), and 'symbol' as holding change with choices (新进, 增加, 不变, 减少). This adds substantial meaning beyond the bare schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning top 10 shareholder holding details from East Money's data center, with the return type explicitly stated as '十大股东' (top 10 shareholders). However, it does not explicitly differentiate from sibling tools like stock_gdfx_free_holding_detail_em, which also deal with shareholder holding details, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios, exclusions, or references to other tools. While the parameter choices are listed, there is no context for when this specific holding-detail tool is preferred over related shareholder-analysis 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the output type (DataFrame) and a source URL, but discloses no additional behavioral traits such as pagination, rate limits, or data freshness. This is acceptable given the strong annotations but not exemplary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is compact and structured with title, URL, parameters, and return type. It is not overly verbose, though the URL may be extraneous for an AI agent and the title largely repeats the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only vaguely specifies 'top 10 shareholders' and a DataFrame, lacking column details. Given the large family of shareholder-related sibling tools, it does not provide enough context to fully understand the result structure or select the correct tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description defines symbol as 'stock code with market identifier' and date as 'reporting period', providing essential meaning beyond bare types and defaults. It compensates for the schema gap, though it could be more explicit about formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates it retrieves top 10 shareholders from Eastmoney for an individual stock, with return type pandas DataFrame. However, it does not explicitly distinguish itself from sibling tools like stock_gdfx_free_top_10_em, which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no exclusions, and no situational context. It only lists parameters and return type, leaving the agent without direction for tool selection.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds a source URL and return type (DataFrame) but does not disclose other behavioral traits such as data freshness, network requirements, or the shape of the returned data. Given the annotations, this is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at three lines. The first line is a Chinese breadcrumb path that largely duplicates the tool's name meaning, and the URL is useful for source identification. It is not overly verbose, but the redundancy keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains, but it only states 'equity pledge market profile' and gives a URL. It leaves column names, data granularity, and whether the data is historical or a snapshot unspecified. This is minimal but sufficient for a zero-parameter read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage), so no parameter documentation is needed. The description adds nothing about parameters, but none exist, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the equity pledge market profile from East Money's data center, with a specific URL and return type (pandas DataFrame). It lacks an explicit verb like 'fetch' or 'get', but the ':return:' phrasing implies retrieval. It does not explicitly differentiate from sibling pledge tools, but the specialized 'market profile' terminology and URL provide enough distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings such as stock_gpzy_pledge_ratio_detail_em or stock_gpzy_distribute_statistics_*. No mention of alternative tools, use cases, or exclusions is present.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only and idempotent nature is pre-established. The description adds practical behavioral context by explaining the adjust parameter (unadjusted, forward-adjusted, adjustment factor) and the return type (pandas.DataFrame). It does not disclose rate limits, date range behavior, pagination, or specific output columns, but given the annotations cover the safety profile, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a title, source URL, parameter definitions, and return type. It is front-loaded with the purpose and each section is informative. The final return line '指定 adjust 的数据' is slightly redundant, but overall the text is compact and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description covers the source, parameter semantics, and return type. However, it omits details about default date ranges, whether the full history is returned, the structure of the DataFrame (column names), and any limitations. Since there is no output schema to provide this information, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It clearly defines the 'adjust' parameter with three valid values ("", qfq, qfq-factor) and notes that 'symbol' can be obtained from another function. It does not specify the exact symbol format beyond a default value and URL example, but this is sufficient for basic usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '新浪财经-港股-个股的历史行情数据' (Sina Finance HK stock individual historical market data), which clearly identifies the resource and the retrieval action. However, it does not explicitly mention 'daily' in the text (implied by the tool name) and does not differentiate from sibling tools like stock_hk_hist or stock_hk_hist_min_em, so it is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives. The only usage-related hint is that 'symbol' can be obtained via ak.stock_hk_spot(), which addresses parameter sourcing rather than tool selection. No exclusions or preferred scenarios are provided, leaving the agent without context for choosing this tool among many similar stock history 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?
Annotations already establish a safe read-only, idempotent operation (readOnlyHint=true, destructiveHint=false). The description adds that it returns a pandas DataFrame and provides the data source URL, but offers no additional behavioral context like rate limits, pagination, or authentication requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring-like structure with a title, URL, parameter, and return type. It is front-loaded with the purpose. The minor inconsistency between the described symbol format and the schema default slightly detracts from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description covers the basic source and return type. However, '实时变动' is vague and does not explain the DataFrame's columns or structure, leaving some ambiguity about what the data contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial meaning to the 'symbol' parameter by stating it must include a market representation (e.g., HK_00700), which is not evident from the schema alone. The default of '00700' in the schema is inconsistent with this format, but the description still provides valuable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches real-time changes for an individual stock's popularity ranking from East Money, with a URL example (HK_00700) providing concrete scope. However, it does not explicitly differentiate this from sibling tools like stock_hk_hot_rank_detail_em, instead relying on the 'realtime' in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any mention of scenarios, prerequisites, or exclusions. The description simply defines the data source and parameter without helping the agent decide when to invoke it.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the source URL and confirms it returns a pandas DataFrame, but does not disclose any additional behavioral traits like data freshness, pagination, or rank criteria.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, containing only the title, URL, and return type. It is front-loaded and has no fluff, but it is so terse that it reads more like a header than an explanatory description. Still, every line conveys something.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no inputs and a clear return type, the description provides the basic purpose. However, it does not explain how this ranking differs from related HK hot rank tools (e.g., latest, detail), and the output content is unspecified beyond '人气榜'. Given the open world hint and absence of an output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema coverage is 100%. Per the baseline for 0-param tools, the description does not need to elaborate on parameters; the description's mention of return type adds minor value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the Eastmoney individual stock popularity ranking for the Hong Kong market, including a source URL and return type. However, it lacks an explicit action verb like 'get' or 'list', relying on the tool name to convey the operation. It distinguishes from siblings by specifying '港股市场'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative tools such as stock_hk_hot_rank_latest_em or stock_hk_hot_rank_detail_em. There is no mention of exclusions, preferred scenarios, or related 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and the return type (pandas.DataFrame), but does not disclose details like data range, columns, or limitations. This is adequate given the annotation coverage, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and structured, with a title line, a source URL, and short docstring entries. The title is repeated at the beginning, which is slightly redundant, but overall the content is well-organized and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations, the description is mostly sufficient: it states the return type and data source. However, it lacks details about the returned DataFrame's columns, date range, or error behavior when an invalid symbol is passed. The absence of an output schema makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with zero description coverage. The description compensates by indicating that 'symbol' is the HK index code and provides the default 'CES100' as an example. This clarifies the parameter's meaning, though it doesn't enumerate all valid codes or how to find them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '新浪财经-港股指数-历史行情数据', which clearly identifies the tool as returning historical market data for Hong Kong stock indices from Sina Finance. It specifies the source (Sina), market (HK indices), and data type (daily historical), but does not explicitly differentiate from sibling tools like stock_hk_index_spot_sina or stock_hk_index_daily_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as the East Money variant (stock_hk_index_daily_em) or the spot variant (stock_hk_index_spot_sina). The description only states what the tool does, without providing context for selection 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the data source URL and return type but no further behavioral context like rate limits, pagination, or authentication requirements. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the tool's purpose and source. However, it redundantly repeats the title and includes a docstring-style layout that could be more concise. Overall, it is appropriately sized and every element contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters and no output schema, the description gives reasonable parameter guidance but fails to explain the structure of the returned DataFrame beyond '盈利预测'. An agent may not know which columns or values to expect. It is minimally adequate but has noticeable gaps in output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by documenting both parameters: symbol as stock code with default 09999, and indicator with allowed choices (评级总览, 去年度业绩表现, 综合盈利预测, 盈利预测概览) and default. It does not specify symbol format details (e.g., zero-padding), but provides essential selection info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 经济通-公司资料-盈利预测 (ETNet Company Data - Profit Forecast) with a source URL, making clear it retrieves profit forecast data for HK stocks. It distinguishes from siblings like stock_hk_profit_forecast_em by specifying the ETNet source, though it lacks an explicit verb phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameters but no guidance on when to use this tool versus alternatives such as stock_hk_profit_forecast_em or stock_profit_forecast_ths. It does not state scenarios, exclusions, or selection criteria, leaving the agent to infer from the source URL alone.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns a pandas DataFrame and provides a source URL, which is useful. However, it does not disclose potential pitfalls such as required code format (e.g., leading zeros) or error behavior. With annotations covering the core safety profile, this level of transparency is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise: a short title, a source URL, and docstring for parameter and return. It avoids excessive verbosity. The URL is a bit long but adds reference value. Overall, it is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should specify the returned data structure. It only says '证券资料' (securities profile) and 'pandas.DataFrame', leaving the fields ambiguous. It also lacks guidance on valid symbol formats or edge cases. For a simple one-parameter tool, this is sufficient for basic use but lacks depth for a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'symbol' is described as '股票代码' (stock code), and the URL example 'code=03900' provides a concrete format illustration. Since schema description coverage is 0%, this description compensates effectively by explaining the parameter and offering a realistic example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides '东方财富-港股-证券资料' (East Money HK Stock Securities Profile), indicating it fetches profile data for a Hong Kong stock. While it lacks an explicit verb like 'get' or 'fetch', the resource and market are clearly identified. It is distinguishable from most siblings, though not explicitly differentiated from the similar stock_hk_company_profile_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or comparison with sibling tools. For an agent selecting among many HK stock tools, this is insufficient.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, non-mutating query. The description adds the source URL and return type (pandas.DataFrame) but does not clarify data scope, pagination, rate limits, or any filtering behavior beyond the symbol parameter. This is adequate but not rich, given the safety profile is already disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the title, source URL, parameter documentation, and return type in a standard docstring format. It is not bloated, but the URL and title are somewhat redundant with the tool name. The information is front-loaded enough for an agent to quickly parse the purpose and parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description only states the return type as pandas.DataFrame and the content as 高管持股变动明细, but it does not describe columns, date ranges, or possible limitations. The single optional parameter is well-documented, making the tool minimally viable, but the lack of usage guidance and return value details leaves gaps for an agent deciding whether to invoke it for a specific task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: it specifies the allowed values for 'symbol' as the choice of {'增持', '减持'} (increase/decrease), which is not present in the input schema. It also confirms the parameter type. This meaningfully adds to the bare schema definition, though it does not explain the semantics of the choices further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving executive shareholding change details (高管持股变动明细) from CNInfo's Data Center thematic statistics section, including the source URL. While it lacks an explicit verb like 'list' or 'get', the docstring-style format with ':return:' implies a data retrieval function. The cninfo suffix in the tool name distinguishes it from the similar EM-based sibling stock_hold_management_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions, prerequisites, or comparisons to the many sibling tools (e.g., stock_hold_management_detail_em, stock_hold_management_person_em). The only context is the source name and URL, which implicitly suggests data origin but not usage scenarios.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the return type (pandas.DataFrame) and the source URL, but does not disclose rate limits, pagination, or the meaning of the ranking data. It adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and uses a clear docstring-like structure with :param and :return. It repeats the title from annotations, which is slightly redundant, but the overall size is appropriate and all sentences are informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should describe the returned DataFrame's columns or content. It only states the return type and the ranking name, leaving the data structure unclear. The tool is simple (one param), but the lack of output detail and usage context makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly lists the allowed values for 'symbol' ('本周新增' and '最热门') and specifies its type as str. This is a meaningful addition beyond the bare schema, though it does not explain the meaning of each value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (Xueqiu Shanghai/Shenzhen hot deal ranking) and the parameter choices. The verb is implied ('returns a ranking'), but the title and return type clarify the action. It does not distinguish from sibling stock ranking tools, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only lists parameter choices and a URL, with no context on use cases, prerequisites, or exclusion of other tools. This is a clear gap.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the return type (pandas.DataFrame) and the source URL, but does not disclose potential behavioral traits such as data freshness, rate limits, or whether scraping may be required. Given the annotations, the additional context is moderate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title line, a URL, and concise param/return docstrings. It is front-loaded with the purpose and structured logically, though the URL line and redundant title could be considered minor clutter. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the parameter choices, return type, and source, which is adequate for a simple one-parameter tool with no output schema. However, it lacks details on the DataFrame's columns, data update frequency, or potential quirks of the Xueqiu source. For a basic ranking tool, this is sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name and default value with 0% description coverage. The description compensates by explicitly listing the valid choices for 'symbol' ("本周新增" and "最热门"), adding meaningful semantics beyond the schema. It could further explain the impact of each choice, but the literal meanings are fairly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: it provides a follow/popularity ranking for Shanghai/Shenzhen stocks from Xueqiu, with a URL to the relevant page. It distinguishes itself from siblings like stock_hot_tweet_xq and stock_hot_rank_em by focusing on the '关注排行榜' (follow ranking), though it doesn't elaborate on what exactly that entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Among many sibling hot/rank tools, there is no explicit differentiation or context about scenarios where this specific follow ranking is preferable. The description only provides the source and parameters, leaving the agent to guess the intended use case.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds no further behavioral nuance (e.g., data freshness, rate limits, or result variability), but also does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, URL, parameter, and return documentation. It is front-loaded and efficient. The URL example is slightly misleading, but overall it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and good annotations, the description provides the return type and parameter meaning. However, it does not explain what hot keywords represent, how they are derived, or the structure of the returned DataFrame beyond 'pandas.DataFrame'. The example URL adds ambiguity about the expected symbol format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a default value with no description. The description explains the 'symbol' parameter as '带市场表示的证券代码' (securities code with market representation) and type str, which is essential for using the tool correctly. The URL example uses 'code=000665' which is slightly inconsistent with the default 'SZ000665', but the parameter description clarifies the format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning hot keywords from East Money's individual stock popularity ranking, using the title and docstring. It includes a URL and parameter/return specs. However, it lacks a clear verb phrase and does not explicitly differentiate from sibling tools like other stock_hot_rank_* functions, though the 'keyword' focus is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no exclusions, prerequisites, or contextual hints. The description only documents parameters and returns without any usage context.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds return type (pandas.DataFrame) and parameter format (securities code with market prefix), which is useful. However, it does not disclose what the DataFrame contains beyond 'real-time change', nor any data freshness or update behavior, so it adds only modest context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a four-line docstring format with title, source URL, parameter semantics, and return type. There is minimal fluff, and key information is front-loaded. The return line is terse but acceptable given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with good annotations, the description covers the essential invocation details. However, the return is described only as '实时变动' (real-time change), which is vague, and there is no explanation of how this differs from closely named siblings like stock_hot_rank_detail_em. An agent might not confidently choose this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter description, but the description explains that symbol is a securities code with market representation (e.g., SZ000665) and provides an example URL. This directly compensates for the schema's 0% coverage, though it does not enumerate all possible market prefixes (e.g., SH, BJ), keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing East Money individual stock popularity ranking real-time changes, with a source URL for context. The verb is implicit (get/retrieve), but the resource and real-time nature are clear. It does not explicitly differentiate from sibling tools like stock_hot_rank_detail_em beyond the word 'realtime', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives. There is no mention of sibling tools, exclusions, or context such as 'use for real-time changes; use stock_hot_rank_detail_em for historical'. The only hint is the tool name and the '实时变动' label, which is insufficient.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that it returns a pandas.DataFrame and specifies the parameter domain, but does not disclose any further behaviors like pagination or data scope limitations. This is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing a title, URL, parameter information, and return type—all in a few lines. Each element adds value, though the structure is more docstring-like than a coherent sentence. It is concise and front-loaded with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the basics: source, parameter choices, and return type. However, it does not explain what the returned DataFrame contains beyond 'discussion ranking', leaving out column details or semantics. This is a moderate gap given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a string parameter with a default, providing no description or enum. The description's ':param symbol: choice of {"本周新增", "最热门"}' fills that gap by listing the exact allowed values, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as Xueqiu's Shanghai/Shenzhen stock market discussion hot ranking, with the title and URL providing clear context. Although there is no explicit verb like 'get' or 'fetch', the intent is clear and it is distinguishable from similar tools (e.g., stock_hot_rank_em) by the 'xq' source and '讨论排行榜' focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or contextual recommendations. The only hint is the parameter choice, which is not usage guidance. This is a clear gap for a tool with many hot-ranking siblings.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the symbol choices, but reveals no other behavioral traits such as data granularity, refresh frequency, or potential quirks. With annotations handling the baseline, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a title, source URL, parameter documentation, and return type. Each line serves a purpose, though the title duplicates the annotation title and the URL may be of limited use to an AI agent. Overall, it is efficient and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, rich annotations, and no output schema, the description is adequate but has gaps. It tells the agent what the data represents at a high level (沪深港通持股-分时数据) but does not specify DataFrame columns, time range, or the meaning of '分时' in practical terms. The absence of usage guidelines further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a default value with no description or enum, and schema coverage is 0%. The description compensates by explicitly listing valid choices: '北向资金' and '南向资金', clarifying the acceptable values for the symbol parameter. This is valuable semantic information beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource (沪深港通市场概括分时数据) and scope (北向/南向资金), distinguishing it from sibling HSGT tools like stock_hsgt_hist_em and stock_hsgt_fund_flow_summary_em by focusing on intraday (分时) data. However, it lacks an explicit verb (e.g., '获取' or 'fetch'), relying on the tool name and context to infer the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative HSGT-related tools. It does not mention scenarios, exclusions, or alternatives, leaving the agent to infer usage from the data type alone. This is a clear gap given the many similar sibling 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description need not repeat safety details. It adds a source URL and return type (pandas.DataFrame), but does not describe the DataFrame's columns, historical depth, or any pagination or rate-limit characteristics. This is partial but not comprehensive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a title, URL, and a standard docstring structure. It includes only relevant information without padding. Slight redundancy exists because the title repeats the Chinese name, but overall it is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the returned DataFrame contains. It only says '市净率数据' (PB data) and the type, which is minimal. It also lacks any note on historical range or data granularity. Given the simple one-parameter nature, the description covers the basics but leaves important details unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a string parameter with a default and no description (0% coverage). The description compensates by fully listing the valid symbol choices ({{"上证50", "沪深300", ...}) and the type (str), which is essential for correct invocation. It does not explain the meaning of each index, but the list itself is sufficient for selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool provides PB (price-to-book) data for specified stock indices via the title '乐咕乐股-指数市净率' and the return statement '指定指数的市净率数据'. It specifies a resource (index PB) and a limited set of supported indices, distinguishing it from generic market PB tools, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention sibling tools such as stock_market_pb_lg or stock_index_pe_lg, and provides no exclusions or prerequisites. The intended use is only implied by the specific index list, but an agent would have to infer when this is the right 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context: it notes the use of an xq_a_token for authentication and that an APIError is raised when a valid login is required. However, it does not describe pagination, rate limits, or behavior on invalid symbols. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a title, source URL, and parameter/return/exception documentation. The URL is useful for verification. It is not verbose and every line contributes to understanding. The only minor issue is the mixing of a raw URL into the prose, but it does not hamper readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should describe the return data in more detail. It states the return type (DataFrame) and content (公司简介/company profile), but does not list the columns or fields included. The authentication requirement is disclosed, and annotations cover safety, but for a tool with no output schema, the description lacks enough detail to fully predict the return structure. It is adequate for a simple lookup but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description's docstring carries the full burden, and it compensates well: each parameter is given a meaningful explanation—symbol as 证券代码 (securities code), token as 雪球财经的 xq_a_token, and timeout as 设置超时时间. The example URL further clarifies symbol format (e.g., NVDA). It would benefit from noting the required format for US symbols, but it is adequate for basic usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '雪球-个股-公司概况-公司简介' (Xueqiu - Individual Stock - Company Overview - Company Profile), clearly stating the resource and data type returned. It specifies a return type of pandas.DataFrame and includes a source URL. However, it does not explicitly mention 'US' stocks within the description, relying on the tool name to distinguish from sibling tools like stock_individual_basic_info_xq and stock_individual_basic_info_hk_xq.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that it is for US stocks, nor does it reference sibling tools for Hong Kong or A-share stocks. The only context is the URL and the tool name, which implies but does not state the 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?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds context about auth requirements (APIError when valid login is needed), the optional token, and DataFrame return type. It does not contradict annotations, but omits external network behavior and potential rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with title, URL, parameter docs, return type, and raised exception. It front-loads the purpose and each line contributes, though the title is redundantly repeated in the annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotations cover safety, but there is no output schema, so the description should clarify the return structure more than just '公司简介 DataFrame'. It also doesn't explicitly state market scope (A-share vs HK/US) or whether symbol is required despite having a default, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% property description coverage, so the docstring compensates by explaining symbol as 证券代码, token as xq_a_token, and timeout as 超时时间. However, it lacks detail on timeout units and the exact symbol format (e.g., SH prefix), preventing a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a Xueqiu individual stock company profile tool, with title '公司简介' and a specific URL. The name and siblings imply A-share scope, but it doesn't explicitly state 'A-share' or distinguish from HK/US variants beyond naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like stock_individual_basic_info_hk_xq or stock_individual_info_em. The URL and source name imply Xueqiu usage, but there are no stated conditions, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that returns a pandas.DataFrame and specifies the data source (East Money), but lacks deeper behavioral context such as pagination, date handling, or any operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter list, and return type. It is structured and free of fluff, though it lacks an explicit opening sentence describing the tool's action in prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description minimally states it returns a DataFrame of announcements, which is adequate but sparse. It does not explain date format expectations, output columns, or how this tool fits among the many stock-related siblings, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by providing Chinese meanings for all parameters: security as stock code, symbol as report type with enumerated choices, and begin/end dates. However, the date format is not specified, and the security code format (e.g., 6-digit with prefix) is not detailed, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function through the title '东方财富网-数据中心-公告大全-个股' and the return type '个股公告', indicating it fetches individual stock announcements. While the verb is implied rather than explicit, it is distinct from sibling tools like stock_notice_report by specifying 'individual' stock scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists parameters and return type, with no mention of prerequisites, exclusions, or comparisons to sibling tools like stock_notice_report.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is useful context, but it does not disclose further behavioral traits such as data scope, date range, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficient, containing a source URL, a return line, and a return type. The title line is somewhat redundant with the annotations but does not add significant waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less, read-only tool with good annotations, the description is mostly adequate. However, it lacks details about the actual content of the returned DataFrame (e.g., columns, date range, coverage), and there is no output schema to compensate for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. No parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns '个股行业分类变动历史' (individual stock industry classification change history), which identifies a specific operation and resource. However, it does not explicitly differentiate from sibling tools like stock_industry_change_cninfo, though the 'sw' and 'hist' hints in the name provide some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 merely states what it returns, with no mention of use cases, exclusions, or relationship to other stock industry 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type, but does not disclose any additional behavioral traits such as rate limits, pagination, or data freshness. With annotations present, the burden is lower, and the added value is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of four short lines: title, URL, return label, and rtype. Each line adds some information, though it is fragmented rather than a coherent sentence. It is not overly verbose and avoids unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only news fetch, the description is adequate: it gives the source, content type, and return type. However, it lacks details about the returned DataFrame's columns, data range, or any limitations. Since there is no output schema, a bit more description of the return structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (empty properties). The description does not need to explain parameters. It does mention the return type as pandas.DataFrame, which is useful for the agent, and with no parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Eastmoney's global financial news flash (全球财经快讯), with a source URL and return type. It distinguishes from siblings like stock_info_global_sina or stock_info_global_ths by naming Eastmoney as the source. However, it lacks an explicit verb like 'get' or 'fetch', relying on the noun phrase and return annotation to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_info_global_cls, stock_info_global_futu, or stock_info_global_sina. The description simply states what the tool is without mentioning use cases, exclusions, or selecting among sibling news sources.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds little beyond confirming it returns a pandas DataFrame and providing a source URL. It does not disclose potential rate limits, pagination, or the nature of 'live' (streaming vs. snapshot), but given the annotation coverage, a middle score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—three lines covering title, source URL, return type, and return description. It is not overly verbose, but it repeats the title in the :return: field and does not add structural detail like column names, which keeps it from being a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description provides basic context: source, return type, and subject. However, it lacks detail on what the DataFrame contains (columns, refresh frequency, language), which is important for an agent to know what to expect. It is minimally sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is nothing to document. Description adds no parameter information, but none is needed. The baseline for no parameters is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides global financial live news from 同花顺 (THS), specifically via the URL. The :return: field indicates it returns a pandas DataFrame of this content. It is distinguishable from siblings like stock_info_global_em and stock_info_global_sina by the THS source. However, it lacks an explicit verb like 'fetch' or 'retrieve', though the context implies 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over the numerous sibling stock_info_global_* variants. It does not mention alternatives, exclusions, or use cases. The usage is only implied by the content type (global financial live), which is insufficient for an AI agent selecting among similar 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds a source URL and return type (pandas.DataFrame), which are useful but minimal. It does not disclose pagination, error behavior, or data coverage, but given annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with title, URL, parameter, and return sections. Each part contributes useful information, though the title line somewhat repeats the tool name. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the source, parameter choices, and return type. However, it lacks details about the returned DataFrame columns, data range, or any examples. It is adequate for simple invocation but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly documents the only parameter 'symbol' with its exact accepted values ('全称变更' and '简称变更') and their mapping to tabs. This is critical information not present in the schema, which only defines a string with a default. Schema coverage is 0%, so the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as Shenzhen Stock Exchange name change data, with a source URL and parameter documentation. It is specific enough to distinguish it from broader stock data tools, though it lacks an explicit verb and does not differentiate from siblings like stock_info_change_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. Sibling tools such as stock_info_change_name, stock_info_sh_name_code, and stock_info_sz_name_code exist, but the description provides no comparisons, exclusions, or contextual usage hints.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the data source (同花顺) and the market segment filter, but does not disclose data freshness, pagination, or other behavioral traits. This is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with standard docstring sections (:param, :return). The first line duplicates the title and the URL is not essential for invocation, but overall the content is not wasteful and each remaining line serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter and no output schema, the description covers the essential retrieval purpose and parameter choices. However, it does not detail the returned DataFrame structure or mention any assumptions about data coverage, leaving some ambiguity for an agent needing to interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides type string and a default, but the description lists the exact allowed choices for the 'symbol' parameter (e.g., '全部A股', '沪市主板'). Since schema description coverage is 0%, this compensation is valuable and gives the agent the necessary constraints to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (同花顺 新股申购与中签) and scope (data for IPO subscriptions and winning results) via the title, URL, and return line. It distinguishes itself from sibling tools that cover other aspects of IPOs (e.g., benefits, HK IPOs), though it lacks an explicit verb like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states what it does and lists parameters, without mentioning exclusions, prerequisites, or when a sibling IPO-related tool might be more appropriate.
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 already declare readOnlyHint=true, destructiveHint=false, establishing the safety profile. The description adds the source URL and that it returns a pandas.DataFrame, but does not disclose data freshness, pagination, or any caveats. With annotations covering the risk profile, the added behavioral context is minimal but not zero, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with five lines covering title, URL, parameter, return type, and return description. It is front-loaded with the title and source, making the purpose immediately visible. The URL line feels slightly disjointed, but overall it is concise and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description is minimally adequate. It covers the parameter and return type, but does not describe the structure of the returned DataFrame or any limitations. The domain-specific name and title help, but an agent might need more detail on what columns or rows to expect. It 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for symbol and no enum, so the description is the only source of semantic meaning. It explicitly lists the allowed values (近一月, 近三月, 近六月, 近一年) and the type, which is essential for correct invocation. It does not explain the exact date ranges implied by these values, but they are self-explanatory enough. This significantly compensates for the schema's 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 个股上榜统计 (individual stock listing statistics) from Eastmoney's Dragon-Tiger List, identifying the resource and scope. It distinguishes from sibling tools like stock_lhb_stock_detail_em by focusing on aggregate statistics per stock. However, the verb is implicit (it does not explicitly say 'get' or 'retrieve'), so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only gives the data source and parameter choices, without mentioning alternative tools or contexts where a different LHB tool would be more appropriate. This is a clear gap.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and parameter domain but does not disclose additional behavioral details such as sorting criteria, data freshness, or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured in docstring format, listing source, params, and returns without excessive prose. It is front-loaded with the identifying title. Minor fragmentation prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations, the description provides the source, valid parameter values, and return type. However, it lacks detail on the exact contents of the returned DataFrame (columns, sorting) and does not clarify how '营业部排行' is defined, which may cause ambiguity among the many LHB sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explicitly enumerates the allowed values for 'symbol' ({近一月, 近三月, 近六月, 近一年}) and specifies the return type. This adds crucial semantic meaning beyond the bare schema definition, which only has a default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the East Money Dragon-Tiger List business department ranking ('营业部排行') and provides the source URL. Although written as a noun phrase rather than a verb phrase, it is unambiguous and distinguishes from siblings like stock_lhb_yyb_capital or stock_lhb_yyb_control by focusing on the ranking aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative LHB tools. The description simply states the data source and parameter choices, without any contextual cues 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), which is useful context, but it does not disclose other behavioral traits such as pagination, date range coverage, or network dependency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three lines: a title, a source URL, and a return type. It is front-loaded and readable, though '资金实力最强' is repeated in the title and return line, adding slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the description does not explain what columns or ranking criteria the returned DataFrame contains, nor how it differs from other longhu ranking tools. Given the absence of an output schema, additional structural detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty properties object). The baseline of 4 applies because there are no parameter semantics to clarify, and the description correctly implies a no-arg call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Tonghuashun's business department ranking by strongest capital strength ('资金实力最强'). It names a specific resource (营业部排名) and includes the source URL, distinguishing it from sibling tools like stock_lh_yyb_control and stock_lh_yyb_most, though it lacks an explicit verb like 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many similar longhu-related sibling tools (e.g., stock_lh_yyb_control, stock_lh_yyb_most), the description does not specify use cases, exclusions, or alternatives, leaving the agent to rely on the title alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a pandas.DataFrame and lists allowed symbol values, but does not disclose additional behavioral traits such as whether data is real-time, whether it reflects a specific date, or potential rate limits. With annotations present, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing only the title, URL, parameter choices, and return type. Each line conveys necessary information without fluff. However, the structure is fragmentary (a mixture of title, URL, and docstring-like param/return) and could be more readable with a prose summary, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what the tool returns. It says 'return: 主力净流入排名' and 'rtype: pandas.DataFrame', but does not specify the columns, the time period (e.g., daily vs. real-time), or any limitations. For a simple one-parameter tool with good annotations, this is adequate but leaves notable gaps about data content and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with a default, and schema description coverage is 0%. The description fully compensates by enumerating the eight valid choices for symbol (e.g., '全部股票', '沪深A股') and specifying the type, which is essential for correct invocation. It adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves the '主力净流入排名' (main net inflow ranking) from East Money's data center, with the URL as source. It identifies the specific resource (capital flow rankings) and the parameter symbol to filter stock universe, distinguishing it from other fund flow tools that focus on individual stocks or sectors. However, it does not explicitly differentiate from siblings like stock_fund_flow_individual or stock_fund_flow_industry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling fund flow tools. There is no mention of alternatives, exclusions, or scenarios (e.g., 'use this for market-wide rankings'). Given the large number of similar tools in the sibling list, this is a significant gap.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns a pandas.DataFrame and provides a source URL, but does not disclose data update frequency, exact columns, or any access limitations. This is modest additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes three pieces of information: source path, URL, and return type. Some repetition exists ('融资融券账户统计' appears in both the path and return), but it is not overly verbose. Each line serves a purpose, though the structure could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description should still convey the nature and scope of the returned data. It states the return is '融资融券账户统计' and a DataFrame, but does not specify whether it covers all markets, the granularity, or the exact fields. The URL provides a reference, but the description is sparse for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so the description has no parameters to explain. Per the rubric, the baseline for 0 parameters is 4. The description does not need to compensate for any parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns '融资融券账户统计' (margin trading account statistics) from a specific Eastmoney data center page. The verb is implied ('return/provide') and the resource is clearly identified. It does not explicitly distinguish from sibling margin tools like stock_margin_sse or stock_margin_szse, but the source URL and title make the specific dataset clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 comparison with other margin account tools. The description only gives the source and return type, leaving the agent to infer usage context.
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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the source URL and return type (pandas.DataFrame), which is useful but minimal. It doesn't describe potential failure modes, rate limits, or whether the data is from a live feed. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title, URL, and return type in a structured format. Each line serves a purpose: identifying the quote source, providing the source URL, and specifying the return type. It is appropriately sized for a zero-parameter tool and is front-loaded with the core purpose. Not overly verbose, though the URL is somewhat extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must convey what the tool returns. It says '实时行情' and rtype pandas.DataFrame, but it doesn't specify the data columns or the exact scope (e.g., all new A-shares on a specific exchange). The garbled text and lack of context about the data content make it incomplete. However, for a simple no-parameter tool, it's minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema fully describes the input. The description adds no parameter-specific semantics, but with no parameters, the baseline of 4 applies. The URL might hint at the data source, but it is not a parameter explanation. No compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '东方财富网-新��-实时行情' which indicates real-time quotes for new shares from East Money, and the title annotation confirms '新股' (new shares). This is a clear verb+resource, but the garbled character and lack of explicit mention of 'A-shares' (though implied by the name) prevents a perfect score. It doesn't explicitly distinguish from sibling tools like stock_cy_a_spot_em or stock_sh_a_spot_em, but the '新股' wording provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or exclusions. The URL is the only context, but it doesn't explain when this tool is the appropriate choice among the many stock spot tools. This is a clear gap.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas DataFrame), providing some value, but it does not disclose other behavioral traits such as data freshness, rate limits, or scope of the returned 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the source and return type. It follows a docstring-like structure (return and rtype) without unnecessary prose. It could be slightly more informative, but it is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimally adequate. It states the source and return type, but it does not describe the columns or the exact nature of the '配股' data, leaving some ambiguity about the returned DataFrame's contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema covers 100% of that (none). With no parameters to describe, the baseline is 4, and the description does not need to elaborate on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (配股/allotment data from Eastmoney) and indicates it returns a pandas DataFrame. Although it lacks an explicit verb like 'get' or 'fetch', the URL and return type imply data retrieval, and it is distinguishable from sibling tools focused on IPOs and other new-stock 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/5Does 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 does not mention any exclusions, prerequisites, or related tools, leaving the agent without context on selection.
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 already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds the source URL and return type, which is useful context, but does not disclose behavioral traits such as network dependency, data update frequency, or potential columns. This is acceptable given the low bar set by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, containing only the data source, URL, and return type. It is concise, but the format is a raw docstring fragment rather than structured prose, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description provides the key facts: what data is returned, the source URL, and the return type. However, it omits details like the DataFrame columns, time range, or update frequency, which would help an agent understand the data fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. According to the rubric, 0 parameters gives a baseline of 4, and the schema coverage is trivially 100%. No additional semantic explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source and content: '东方财富网-数据中心-新股数据-增发-全部增发' (Eastmoney Data Center - New Stock Data - Additional Issuance - All Additional Issuance) and specifies the return type as pandas.DataFrame. It is a specific resource, though it lacks an explicit verb like 'get' or 'list' and does not differentiate from sibling 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/5Does 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 vs alternatives. It does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer usage solely from the description.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that the return is a pandas DataFrame and gives the source URL, which is useful context but does not disclose additional behavioral traits such as network dependency, data freshness, or output contents. This meets the baseline expected when annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, consisting of a title, a URL, and return type lines. It avoids unnecessary words and is easy to scan. However, the 'return: 持续缩量' line is somewhat redundant with the title, and a more structured sentence could improve clarity without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description provides the essential purpose and source, but it does not describe the DataFrame structure, columns, or the exact ranking criteria beyond the phrase '持续缩量'. Without an output schema, the description is expected to elaborate on return values; it only gives a terse label. This is adequate but leaves some gap for an agent seeking full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects this with 100% coverage. The description does not need to explain parameters since there are none, and the baseline for no-parameter tools is 4. The description does not add any misleading parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (同花顺-数据中心), the category (技术选股), and the specific indicator (持续缩量), along with a URL. It clearly indicates this tool provides a ranking list of stocks with continuous volume contraction, distinguishing it from sibling tools by suffix. However, it lacks an explicit verb like 'get' or 'fetch', relying on the tool name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. Sibling tools cover other technical indicators (e.g., stock_rank_cxd_ths for a different strategy), but no differentiation or selection criteria are stated. Usage must be inferred solely from the tool name and the small descriptive phrase.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose any additional behavioral traits such as data scope, pagination, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a docstring structure with title, URL, parameter, and return sections. It includes the title redundantly and a long URL, but overall remains compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the basics: what it returns and the parameter meaning. However, it lacks detail on the contents of the returned DataFrame (e.g., columns, scope), and provides no comparison with similar rating tools, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description defines 'date' as the query date (查询日期) and specifies its type as str, adding meaning beyond the bare schema. It does not explicitly state the date format, but the schema default '20230817' implies YYYYMMDD.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as investment ratings (投资评级) from CNInfo, and the return type is specified as a pandas DataFrame. However, it lacks an explicit action verb like 'fetch' or 'retrieve', and does not distinguish itself from other rating-related tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only includes parameter documentation and a source URL, with no context about use cases 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns a DataFrame, but does not disclose any further behavioral details such as data freshness, column schema, or errors. Thus it adds modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief: a Chinese title, a URL, and a return annotation. While compact, it reads as unpolished fragments rather than a structured description. It earns a 4 for appropriate brevity given the zero-parameter interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool with robust annotations, the description provides the essential return type and source URL. However, it lacks any guidance on expected columns, use cases, or relationship to other stock register tools, so it is merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing for the description to meaningfully elaborate. The description's mention of return type and data source is irrelevant to parameters. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool returns 科创板注册制审核结果 (STAR Market registration review results) as a pandas DataFrame, distinguishing it from sibling stock_register_* tools via the explicit 科创板 (STAR Market) qualifier. However, it lacks a direct verb like 'get' or 'retrieve,' making the action implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_register_cyb or stock_register_all_em. It only gives a data source URL and return type, with no mention of exclusions or preferred use cases.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose additional behavioral details such as data granularity or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the title, but it is somewhat fragmentary, consisting of a title, URL, and return type. It is not wasteful, but it lacks a clear sentence structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description identifies the source and return type, but leaves the actual data contents vague ('stock repurchase data'). With no output schema, the agent may not know what columns or time period to expect, making completeness moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score of 4 applies. The description does not need to explain parameter semantics, and it correctly does not attempt to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource clearly: '股票回购数据' (stock repurchase data) from East Money's data center, with a specific URL. It distinguishes from siblings by topic, but lacks an explicit verb like 'get' or 'fetch', making it more a title than a complete purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any conditions, exclusions, or alternative tools, leaving the agent without context for selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds only the return type (pandas.DataFrame) and source URL, without further behavioral disclosure (e.g., columns, pagination, rate limiting). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a source URL, parameter documentation, and return type, with no filler content. The first line duplicates the annotation title, but overall the length is appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only states that the return is a pandas DataFrame of '个股限售解禁' without detailing columns or data contents. It provides enough to attempt a call (parameters and source), but not a complete picture of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description gives meaning to both parameters: symbol is '股票代码' and date is explained as a date string obtained via another function. This adds operational guidance beyond the schema defaults, though it does not specify date format explicitly (the schema default shows YYYYMMDD).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a source path with no explicit verb (e.g., 'get', 'list'), just names the resource '东方财富网-数据中心-个股限售解禁-解禁股东'. The parameter and return docs imply retrieval, but the purpose is stated as a noun phrase rather than a clear action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The date parameter is described as '通过 ak.stock_restricted_release_queue_em(symbol="600000") 获取', which implies a dependency and workflow, and an example URL is given. However, there is no explicit comparison to sibling tools (e.g., stock_restricted_release_detail_em or queue) or when to prefer this one.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds the data source (Sina) and return type (pandas.DataFrame), which is useful but does not disclose any rate limits, pagination, or data freshness behavior. This aligns with the calibration example where annotations lower the burden but the description still lacks rich 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and functional, consisting of a title, source URL, and docstring-style parameter/return annotations. There is no wasted text, and the structure is clear. It is slightly sparse, but every line serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return data more thoroughly. It only states '指定 indicator 的数据' (data for the specified indicator) and the rtype, leaving column names or data granularity unspecified. The tool is simple, and the parameter choices are covered, but the return structure is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by listing the allowed values for the 'indicator' parameter: {'新浪行业', '启明星行业', '概念', '地域', '行业'}. This adds significant meaning beyond the schema's basic type/string and default definition, though it does not explain what each choice returns in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves sector quotes from Sina Finance with the Chinese phrase '新浪行业-板块行情' and provides the source URL. It is specific about the resource (sector quotes) but does not explicitly differentiate from sibling tools like stock_sector_detail or stock_sector_fund_flow_rank, hence not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists parameter choices but does not mention any exclusions, prerequisites, or contextual scenarios. The only implicit usage is from the tool name and the description's mention of different indicator categories, which is insufficient.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the API endpoint (p_stock2215) and return type (pandas.DataFrame), but no additional behavioral context such as date format handling, pagination, or potential errors. With annotations present, this moderate addition earns a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, a reference URL, and parameter/return documentation. Each line contributes useful information without redundancy. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description at least specifies the return type (pandas.DataFrame) and content (company share capital changes). However, it omits practical details like date format (implied by defaults but not stated), whether the date range is inclusive, and any behavior when no data is found. For a straightforward query tool this is adequate but has clear minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It provides Chinese definitions for each parameter: symbol=股票代码, start_date=开始变动日期, end_date=结束变动日期, and also describes the return as 公司股本变动 (pandas.DataFrame). This compensates well for the missing schema descriptions, though date format is not explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the Chinese title '巨潮资讯-股本股东-公司股本变动' (CNINFO - Shareholders - Company Share Capital Changes) and states it queries the p_stock2215 API. This clearly identifies the tool's function of retrieving company share capital change data. It is specific enough to distinguish it from many siblings, though it does not explicitly compare against similar cninfo stock 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/5Does 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, no prerequisites, and no exclusions. The description only documents parameters and return type. Given the large sibling list, the lack of contextual selection guidance is a clear gap.
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 already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds the source URL and the symbol option ('全部' vs specific code), but does not disclose edge cases, such as handling of invalid stock codes or data coverage limits. This is acceptable given the annotation coverage 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring pattern with title, URL, param, and return. The title line duplicates the annotation title, but the rest is efficient and well-structured with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only specifies the return type as pandas.DataFrame without detailing columns or data availability. For a single-parameter read-only tool, this is adequate but leaves the agent without information about the DataFrame's structure, which could impact downstream processing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with default '430489' and no description. The description adds crucial meaning by stating the parameter accepts '全部' (all) or a specific stock code, which is essential for agent usage. However, it does not explicitly format the stock code requirement beyond the default example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as Beijing Stock Exchange regulatory information on shareholding changes by directors, supervisors, and related personnel, and the tool name implies the retrieval action. It clearly distinguishes from sibling tools for SSE and SZSE via the explicit mention of '北京证券交易所'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like stock_share_hold_change_sse or stock_share_hold_change_szse. The description only includes parameter and return documentation, leaving the agent to infer appropriate usage from the exchange-specific name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), but says nothing about output columns, pagination, or data range. With annotations present, this level of extra context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a title line, source URL, and docstring-style param/return annotations. It is front-loaded with the most important information and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned DataFrame contains, but it only repeats '董监高人员股份变动' without column names or examples. It also does not clarify the valid values for symbol ('全部' vs a specific code) or mention data coverage. The tool is simple, but these gaps leave an agent uncertain about the result structure and parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's docstring is the only source of parameter meaning. It explains that symbol accepts '全部' or a specific stock code, which adds value beyond the bare schema. However, it does not enumerate the exact allowed values or clarify that the parameter is optional (despite the schema default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource: '上海证券交易所-披露-监管信息公开-公司监管-董董监高人员股份变动' (SSE disclosure of shareholding changes by directors/supervisors). It clearly distinguishes from sibling tools for other exchanges (e.g., _szse, _bse) by explicitly mentioning Shanghai Stock Exchange. Though it lacks an explicit verb like 'get' or 'list', the intent to retrieve this data is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description: this tool is for SSE-listed company shareholding changes. However, there is no explicit guidance about when to use this tool versus alternatives (e.g., stock_share_hold_change_szse or stock_share_hold_change_bse), nor any mention of exclusions or prerequisites.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the source URL and return type, but does not disclose potential pagination, rate limits, or the meaning of 'uid=65'. No contradiction, but limited additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title, followed by the URL and docstring lines. It avoids unnecessary prose, though it repeats '提问与回答' in multiple places. Overall it is efficient for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return format more thoroughly; it only says '提问与回答' and rtype str. It does not describe the structure or content of the Q&A data, nor any edge cases. For a simple read-only retrieval tool, this is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents the parameter 'symbol' as '股票代码' (stock code), which adds meaningful context beyond the raw schema's type and default. It also specifies its type as str, compensating for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title '上证e互动-提问与回答' clearly indicates the tool retrieves Q&A from SSE e-Interactive, and the URL confirms the exact source. The verb is implied (get/fetch) but not explicitly stated, and it doesn't explicitly differentiate from sibling tools, though the name makes it fairly unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other stock-related tools, such as stock_news_em or stock_zh_a_hist. It does not mention prerequisites, alternatives, or exclusions. The only context is the source URL and parameter documentation.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds minimal behavioral context beyond that, such as the return type (pandas.DataFrame) and the note that the date should reference the website. It does not mention pagination, data volume, or any side effects. Since annotations cover the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear structure: title, URL, parameter doc, and return doc. It is front-loaded with the key information and does not contain unnecessary verbosity. The URL and param/return sections are all relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema, so the description carries the burden of explaining the return. It states that it returns a pandas.DataFrame of individual stock goodwill details, but does not describe the columns or any specifics about the data. It also does not differentiate from sibling tools in usage context. For a simple data retrieval tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that the single parameter 'date' is the data date as specified by the website, and specifies its type as str. This adds meaning beyond the bare schema, though it could be more specific about the date format or valid values. Given the single parameter, it adequately compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (East Money individual stock goodwill details) and provides a source URL, distinguishing it from similar stock_sy_* tools by specifying '个股商誉明细'. However, it lacks an explicit action verb like 'fetch' or 'list', making the purpose slightly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its siblings such as stock_sy_hy_em or stock_sy_jz_em. It only mentions that the date parameter should follow the website's specification, which is a parameter-level hint, not tool selection guidance. No alternatives or exclusions 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and parameter choices ('当月'/'当年'), which provides context beyond annotations, but does not mention edge cases or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the Chinese title and URL. It efficiently lists parameters and return type without unnecessary verbosity. The docstring-style structure is clear and every line contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the source URL, parameter meanings, and return type (pandas DataFrame), which is adequate for a simple read-only tool. However, it does not describe the columns or structure of the returned data, and with no output schema, a bit more detail on the expected data shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), but the description meaningfully explains both parameters: symbol is a choice of {'当月', '当年'} and date is 交易年月 (trading year-month, with default '202501' illustrating format). This compensates for the missing schema descriptions, though the exact date format is implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Shenzhen Stock Exchange stock industry trading data (股票行业成交数据), with the title confirming it's a sector summary. It distinguishes from siblings by specifying SZSE and sector-level data, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions or recommend sibling tools for related needs, leaving the agent to infer from the name and title alone.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds modest context by specifying the param is the most recently ended trading day and the return type is a pandas DataFrame. However, it does not disclose other behavioral traits such as pagination, rate limits, or data availability, so it stays at a baseline level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title, source URL, parameter documentation, and return type. It avoids unnecessary words and is well-structured as a docstring. While it is brief, it contains no fluff and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description provides the essential information: the source, the date parameter semantics, and the return type. However, it lacks details about what specific categories are included, any prerequisites, or guidance on when to use it among the many sibling tools. Given the simplicity, it is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema for 'date' has no description, so the :param date: 最近结束交易日 explanation in the description is essential and helpful. It clarifies the meaning of the parameter, which is all that is needed for a single-parameter tool. This compensates well for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing securities category statistics from the Shenzhen Stock Exchange overview page. The title '深证证券交易所-总貌-证券类别统计' is specific and distinguishes it from similar summary tools like stock_sse_summary or stock_szse_area_summary. While it lacks an explicit verb like 'get' or 'retrieve', the return type and context make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other market summary tools. It does not mention alternatives, exclusions, or conditions under which this tool should be selected. This is a significant gap given the large number of sibling tools dealing with market summaries and statistics.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by specifying the return type (pandas.DataFrame) and that data is real-time ('实时行情'), plus the source URL. However, it does not disclose details like update frequency, pagination, or how invalid symbols are handled, and it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured as a docstring: source, URL, parameter, return, and return type. It avoids unnecessary prose. The only minor issue is that the first line duplicates the annotation title, but it still serves as a clear header. Overall, every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers the source, parameter, and return type. However, it does not clarify what columns the DataFrame contains, what constitutes '知名美股', or whether the result is a list of all stocks in a category. Given the lack of an output schema, a bit more detail on the returned data would be beneficial, but the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with a default value, lacking an enum or description. The description compensates by enumerating the valid choices: {'科技类', '金融类', '医药食品类', '媒体类', '汽车能源类', '制造零售类'}, which is essential for using the parameter correctly. It also labels it as a 'choice' (choice), adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '知名美股' (famous US stocks) from 东方财富网 and states the return is '知名美股实时行情' (real-time quotes), which effectively conveys the tool's function. It distinguishes from siblings like stock_hk_famous_spot_em by the explicit '美股' (US stock) and '知名' (famous) scope. However, it lacks an explicit action verb like 'get' or 'fetch', relying on the return statement to imply retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_us_spot_em or stock_us_pink_spot_em. It only gives the source and parameter choices without contextual cues like 'use this for famous US stock quotes by category'. There is no exclusion or 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the source URL, parameter choices, and return type (pandas.DataFrame), which provide some context but do not disclose data freshness, error behavior, or symbol format nuances beyond the example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title and URL, followed by parameter documentation. It is not overly verbose, though the docstring format is a bit repetitive with the type lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and read-only, and the description plus annotations cover the essentials: parameters, choices, return type, and safety. However, it does not mention defaults (which are in the schema), potential errors, or how the symbol should be formatted (the URL uses 'us-NVDA' while the default is 'NVDA'), leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema description coverage by documenting each parameter: symbol as a stock code string, indicator with five explicit choices, and period with three choices. This is valuable, but it stops short of explaining the meaning of each indicator or the exact accepted symbol format (e.g., 'NVDA' vs 'us-NVDA' from the URL).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a Baidu Gushitong US stock valuation data tool, with an example URL and return type, distinguishing it from Hong Kong and A-share valuation siblings. However, it lacks an explicit verb like 'retrieve' or 'get,' relying on the noun '估值数据' to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_us_hist or stock_zh_valuation_baidu. The description only states what it returns, not under what circumstances it should be selected, and no exclusions 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds some useful context: it gives the data source URL, specifies that the date parameter starts from 20100331, and indicates the return type (pandas.DataFrame). However, it does not disclose any additional behavioral traits such as network request behavior, pagination, data freshness, or potential delays, which would be valuable but are not strictly required given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and well-structured, using a docstring-like format with a title line, URL, and parameter/return documentation. The URL provides a useful reference for the data source. There is slight redundancy with the title being repeated in the description, and the return line is minimal, but overall every line contributes functional information without excessive padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description covers the essential usage details: data source, parameter format/range, and return type. It is adequate for basic retrieval. However, it lacks any discussion of the DataFrame's columns or contents, and it does not qualify how this tool relates to similar financial reporting tools, which is contextually relevant given the large sibling set. An agent might successfully invoke it but may not understand what data fields to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the property name 'date', type string, and a default value, with 0% schema description coverage. The description compensates well by explaining the parameter as '财报发布日期' (earnings report release date), providing concrete format examples ({'20200331', '20200630', ...}), stating the valid range (from 20100331), and confirming the type as str. It also documents the return type as pandas.DataFrame. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as accessing East Money's performance express (业绩快报) data by date, as seen in the title and URL. It specifies the resource (annual/quarterly report express data) and the key parameter (report release date). However, it does not explicitly distinguish this tool from closely related siblings like stock_yjbb_em (业绩报表) or stock_yjyg_em (业绩预告), which could lead to ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 documents the 'date' parameter and return type. Given the presence of many sibling tools for financial data (e.g., stock_yjbb_em, stock_yjyg_em), it would be valuable to state that this tool is specifically for 业绩快报 (performance express) data, but no such comparison or usage context is given. This is essentially no guidance.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safe read profile is covered. The description adds context about the data source (East Money), URL structure, and date availability ('从 20081231 开始'), which is useful. However, it does not disclose output columns, pagination, or other behavioral details, so it only partially adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a clear docstring structure with title, URL, parameter, and return sections. It is front-loaded with the purpose. There is minor redundancy since the title repeats the annotation title, but overall every line serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description covers the basics: source, parameter, and return type. However, the return is described only as '业绩预告' with no detail about DataFrame columns or content, which is insufficient since there is no output schema. The tool's context is not fully specified for an agent to judge if it meets the user's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a default value with no description (0% coverage). The description compensates by documenting the 'date' parameter as the financial report release date, listing valid examples (20200331, 20200630, etc.), and noting the earliest available date (20081231). This adds meaningful semantics beyond the schema, though it could be more explicit about the exact format and whether only quarter-end dates are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves annual/quarterly performance forecasts (业绩预告) from East Money's data center, as shown in the title and the ':return: 业绩预告' line. The URL provides a concrete reference. However, it does not explicitly distinguish itself from sibling tools like stock_profit_forecast_em, which also deals with profit forecasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lacks any mention of exclusions, alternative tools, or specific use cases. The only guidance is parameter-related, which is not usage context.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL, the date parameter's meaning, and the return type (pandas.DataFrame), which is useful, but it does not disclose additional behavioral traits such as output columns, pagination, or potential rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title line, source URL, and a docstring with param/return info. Each line serves a purpose, though the URL might be redundant for an AI agent. It is well-structured and contains no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 provides the source, parameter meaning, and return type. However, it does not detail the output columns or the exact nature of the '一致行动人' data, which could be important for an agent to correctly interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions, so the description must compensate. It explains the date parameter as '每年的季度末时间点' (year-end quarter end time point) with type str, adding meaning beyond the schema's bare type definition. However, it does not specify the exact date format or allowed values beyond the default '20240930'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 一致行动人 (concerted action persons) from East Money's data center, and includes the source URL. It distinguishes this tool from siblings by naming the specific dataset, though it lacks an explicit verb like 'retrieves' or 'queries'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only contextual hint is the parameter description '每年的季度末时间点' (year-end quarter end time point), but there is no explicit discussion of appropriate use cases or exclusions compared to other stock_* 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safe read-only nature is clear. The description adds context about the data source (East Money data center) and return type (DataFrame), which is useful. However, it does not disclose behaviors like data range limits, pagination, or potential differences in data availability across dates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title line, URL, and parameter/return documentation. It repeats the title that also appears in annotations, but it is still concise and well-structured. The information is front-loaded, with the main purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description must carry more weight. It states the return is a pandas DataFrame and the parameter options, but it omits details about what columns the DataFrame contains (e.g., total assets, liabilities) and does not clarify that 'bj' signifies Beijing Stock Exchange. This leaves some ambiguity for an agent selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists 'date' with a default but no description, so the description must compensate. It does so by specifying the date format (YYYYMMDD), giving example values like 20200331 and 20200630, and noting the valid range starts from 20100331. This adds meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a balance sheet (资产负债表) from East Money's data center for annual/quarterly reports. The verb is implied ('get' or 'retrieve') and the resource is specific. However, it does not explicitly distinguish itself from the similarly named sibling tool stock_zcfz_em, beyond the 'bj' suffix in the tool name which suggests Beijing Stock Exchange but is never mentioned 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/5Does 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 only documents the parameter format and return type. It does not specify that this tool is for Beijing Stock Exchange balance sheets or contrast it with related tools like stock_zcfz_em.
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 already declare the tool is read-only, idempotent, and non-destructive. The description adds date-range parameter semantics and a pandas.DataFrame return type. However, the stated return object ('股东大会' – shareholders' meeting) contradicts the tool's stated purpose of major contract details, reducing trust in the output description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, URL, parameter docs, and return type. It is reasonably structured but includes an unnecessary URL and a misleading return value ('股东大会'). The error and redundancy prevent a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain what the returned DataFrame contains. It incorrectly states the return is '股东大会' instead of the expected major contract details. For a simple two-parameter tool, this missing/incorrect output description is a significant gap that could cause an agent to misinterpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It clearly documents both start_date and end_date with Chinese labels, types (str), and concrete format examples (e.g., 20200819). This gives an agent all necessary information to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '重大合同明细' (major contract details) from East Money Data Center and provides the source URL. The title is specific and distinguishes it from sibling tools, though no explicit verb like 'fetch' or 'retrieve' is used. The incorrect return type ('股东大会') slightly muddies the 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/5Does 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 alternative stock data tools. The description only documents parameters and returns, with no mention of use cases, exclusions, or alternative tools. This is a clear gap given the large sibling set.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to cover basic safety. It adds the data source URL and return type (pandas.DataFrame), which provide some context about output format, but it does not disclose other behavioral traits such as pagination, rate limits, or the specific columns in the returned DataFrame. This is acceptable but not enriched beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with source URL, parameters, and return type. It is not verbose and every line adds something, though the URL line is somewhat redundant with the title. It remains well-organized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 tells the agent the input (symbol) and the return type (pandas.DataFrame), but it does not detail what columns or data the '股东户数详情' (shareholder count details) actually contains. It is minimally sufficient but leaves ambiguity about the structure and scope of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with no description (0% schema coverage), so the description carries the burden. It explains ':param symbol: 股票代码' (stock code) and gives an example URL using 000002, clarifying the expected input format. It also states the return type, adding meaning beyond the bare parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Eastmoney Data Center - Shareholder Count Details) and provides an example URL, making it clear this tool retrieves shareholder count detail data for a given stock. It lacks an explicit verb like 'retrieve' or 'get', but the intent is clear. It does not explicitly distinguish from sibling tools like stock_zh_a_gdhs, though the 'detail' in the name and description offers some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools, exclusions, or specific use cases. The description simply states the data source and parameters, leaving the agent without context for selecting this tool over others.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the data source URL and return type (pandas.DataFrame) but does not disclose details like data freshness, universe definition, or limitations. This adds some value beyond the annotations but leaves behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a title, a URL, and return type annotations. It is front-loaded and contains no fluff. It follows a standard docstring structure. However, it is so short that it approaches under-specification, though it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter, no-output-schema nature of the tool, the description covers the source and return type. However, it fails to explain what '次新股行情数据' actually contains, such as which stocks are included, column names, or whether the data is real-time or historical. In the context of many similar stock tools, more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete. Since no parameters exist, the description does not need to explain parameter meanings. The baseline of 4 applies because there is no parameter burden to compensate for, and the description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing new stock (次新股) market data from Sina Finance. It clearly distinguishes the tool from siblings by specifying the 'new stock' segment of the Shanghai/Shenzhen market. The lack of an explicit verb like 'fetch' or 'get' is a minor gap, but '行情数据' clearly implies data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool compared to alternatives such as stock_zh_a_spot_em or stock_zh_a_new_em, nor any exclusions or prerequisites. The description gives no context for tool selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the source URL and return type (pandas DataFrame), but no additional behavioral traits like rate limits, pagination, or network dependencies. Since annotations cover the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with three useful lines: source/scope, URL, and return type. The URL might be extra but provides context. It is not padded or verbose, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description conveys the basic purpose and return type. However, it does not detail what 'new stocks' means (e.g., listing time window), the columns in the DataFrame, or any other constraints. Given the many sibling stock tools, a bit more explanation of the exact data would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter information is needed. According to the rubric, 0 parameters gives a baseline of 4. The description correctly provides no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (东方财富网/行情中心/沪深个股/新股) and the output (新股, pandas DataFrame). The verb is implicit rather than explicit, but the resource and scope are clear. The mention of Eastmoney and URL helps distinguish from siblings like 'stock_zh_a_new'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 similar siblings (e.g., 'stock_new_a_spot_em', 'stock_zh_a_spot_em'). There is no comparison, prerequisites, or alternative recommendations, making it purely a data-source docstring.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about the source (East Money page) and return type, but does not discuss data freshness, column structure, or potential network behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, containing essential elements: source, content, and return type. It is appropriately sized for a no-parameter tool, though the first line simply mirrors the title, which is a slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-fetch tool, the description identifies the exact data source and content, and the return type is clear. However, it omits usage guidance, differentiation from similar tools, and details about the DataFrame columns, which would be valuable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so with 100% schema coverage, the description need not explain parameters. It does add value by stating the returned dataset (two networks and delisted stocks), providing meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '两网及退市' (two networks and delisted stocks) from East Money and specifies the return type as a pandas DataFrame. However, it lacks a direct verb like 'get' or 'list' and does not differentiate from sibling tools such as stock_zh_a_st_em or stock_staq_net_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides a source URL and return type, leaving the agent to infer its purpose among many similar stock list 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the function returns a pandas DataFrame and accepts page-range parameters, which gives some behavioral context. However, it does not disclose potential rate limits, the nature of the 'report content' beyond a vague label, or whether the data is scraped in real-time. With annotations handling safety, this seems 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured as a docstring with distinct sections for description, URL, parameters, and return. There is slight redundancy (repeating '科创板报告内容' as the description and return), but the text is short and easy to parse. Every element except the title repetition serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, no output schema), and the description states the return type (DataFrame) and the resource. However, it does not elaborate on what the DataFrame contains (columns, report types) or any caveats about the data source. For a paginated report retrieval tool, this is a modest gap but not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by explicitly documenting both parameters: from_page (start page) and to_page (end page). This adds meaningful semantics beyond the schema's type/default information. However, it lacks details on page size, ranges, or value constraints, but the basic meaning of each parameter is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves STAR Market (科创板) report content, with a source URL (data.eastmoney.com/notices/kcb.html) that grounds it in a specific data source. Although the verb is implicit rather than explicit (e.g., 'fetch'), the combination of the title, name, and parameters makes the purpose reasonably clear. It does not explicitly differentiate from sibling tools like stock_research_report_em or stock_zh_kcb_daily, but the specific reference to report content and the URL narrows the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, context for typical use, or exclusions. It simply states the resource and parameters, leaving the agent to infer when this tool is appropriate from the name and URL alone.
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 already declare readOnlyHint=true and idempotentHint=true, so the description's job is lighter. It adds the return type (pandas.DataFrame) and source URL, which provides some behavioral context, but does not disclose any caveats like handling of non-trading days or data limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, using a standard docstring format with source URL, param, and return sections. Every sentence adds value and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is adequate but not complete. It covers the source, parameter, and return type, but lacks output column details, behavior when the market is closed, or any distinction from closely related limit-up pool tools. Given no output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with no description (0% coverage), so the description must compensate. It states 'date' is a trading day and shows a default value '20241008' indicating the YYYYMMDD format. However, it does not explain whether the parameter is required, how to handle invalid dates, or what happens if omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the '涨停股池' (limit-up stock pool) from East Money's market center, with a source URL and parameter/return info. It is specific about the resource and verb, though it does not explicitly differentiate from sibling limit-up pool tools like stock_zt_pool_dtgc_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no exclusions, and no context about suitable scenarios. It only mentions the parameter and return type, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the source URL and DataFrame return type but no additional behavioral details such as update frequency, data scope, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, consisting of a title, URL, and return specifications. It avoids unnecessary text, but the lack of a full descriptive sentence slightly reduces clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least explain what the trading calendar DataFrame contains. It states 'trading calendar' and rtype pandas.DataFrame, but does not describe columns, date range, or update behavior, making it minimally complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description needs no parameter explanations. The baseline for zero-parameter tools is 4, as the schema fully covers the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as Sina Finance's historical trading calendar data, including a source URL and return type. It is distinguishable from sibling tools by its specific focus on trade dates from Sina, though it lacks an explicit verb phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives. The description gives no usage scenarios, prerequisites, or exclusions, leaving the agent without selection guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (DataFrame) and source URL, but does not disclose other behavioral traits such as pagination, data freshness, or any limitations. It is consistent with annotations, hence not contradictory, but adds limited behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a title, URL, and return type in three lines. It is front-loaded with the main identifier and contains no fluff. However, it is a bit terse and could be slightly more informative without being wasteful, earning a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should compensate by detailing what data is returned. It states '综艺节目' (variety shows) and 'pandas.DataFrame', but does not specify columns, time range, or content granularity. For a simple no-parameter read-only tool, this is acceptable but leaves room for improvement. A more complete description would mention typical fields like program name, rating, or release date.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to compensate for parameter documentation since there are none. It correctly omits parameter explanation, and the schema coverage is 100% by default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving variety show (综艺节目) data from the Endata video platform, with a specific URL and return type. The verb is implied but not explicit; the naming and context distinguish it from siblings like video_tv. It lacks an explicit action word like 'get' or 'list', but the resource and scope are 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/5Does 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 exclusions, prerequisites, or comparison with sibling tools. For a simple no-parameter tool, the context is clear that it returns variety show data, but no when-to-use guidance is given.
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 already declare the operation as read-only, idempotent, and non-destructive. The description adds the source URL and the year range (2003-present), plus a return type of pandas.DataFrame. However, it does not disclose behavior for invalid years, the nature of the ranking data, or any potential errors. Given the annotation coverage, the description provides modest additional context but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring-like structure with a title, source URL, parameter documentation, and return type. It avoids unnecessary verbosity and packs essential information into a few lines. The URL is a bit of clutter but provides the data source, making it useful overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, it provides essential information: source, parameter range, and return type. However, without an output schema, the return value is only described as '排行榜' (ranking list) and pandas.DataFrame, which leaves ambiguity about the specific columns or data details. It is adequate but has clear gaps in fully specifying what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the 'year' parameter, but the description includes ':param year: 具体排名年份, 数据从 2003-至今', which clarifies that year is a string representing the ranking year and provides a valid range. This compensates for the schema's lack of description. It could be more explicit about the expected format (e.g., 'YYYY'), hence not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as the '新财富 500 人富豪榜' and includes a source URL, clearly indicating it retrieves the New Fortune 500 Richest ranking. It distinguishes from sibling tools like forbes_rank and hurun_rank by naming the specific source '新财富', but it lacks an explicit action verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when to choose this over forbes_rank or hurun_rank, nor does it state any exclusions or prerequisites. The only contextual clue is the data range '2003-至今', which is parameter information rather than usage guidance.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds the official source URL and indicates it is a public information disclosure, but it does not disclose additional behavioral details such as columns, pagination, or update behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, presenting the source category, URL, and return type in a scannable format. The ':return:' line repeats the content in the first line, but overall it remains appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter public data listing backed by strong annotations, the source URL and return type provide sufficient context. It does not enumerate returned fields, but the low complexity makes that less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so no parameter descriptions are necessary. The input schema fully defines the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource: AMAC public disclosure of bond investment trading related personnel, including the source URL and return type. It also differentiates from the sibling amac_person_fund_org_list by explicitly stating '债券投资交易相关人员公示'. However, it lacks an explicit action verb like 'retrieve' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related AMAC personnel, fund, or bond disclosure tools. The description only states the data source and return value, leaving usage decisions to inference from the tool name.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds a source URL and return type but does not disclose additional behavioral traits such as pagination or response format. With annotations covering the safety profile, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a source label, a URL, and return type information. Every element adds essential context, and it is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotations cover safety, but the description does not explain the structure or contents of the returned list (e.g., whether it contains codes, names, or objects). Since there is no output schema, this leaves a minor gap for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, so there are no parameter semantics to explain. The empty input schema with 100% coverage means the description does not need to compensate for any parameter documentation gap, aligning with the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning available options from the non-specified-maturity portion of the China Bond Index family, with a source URL and return type. It implies a list retrieval function, though it doesn't explicitly name alternative sibling 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/5Does 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 other bond index tools or alternatives. It only states what it returns, not when it is the appropriate choice.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URLs, the explicit date range constraint, and the return type as pandas.DataFrame. It does not describe pagination or output columns, but with annotations, this is a modest addition without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a title, two URLs, a note, and parameter/return docstrings. It is structured and avoids excessive length. The URLs add useful provenance, though the second URL is a long example that could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter query tool, the description covers the basic data source and return type. However, it fails to specify the accepted date format (schema defaults use YYYYMMDD while the example URL uses YYYY-MM-DD), and the return line is garbled. The absence of output schema makes the lack of column details a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It provides docstrings for start_date and end_date, explaining that each defines a one-year window, and notes the interval must be less than a year. However, the wording is somewhat confusing and repetitive, and it does not clarify the date format (e.g., YYYYMMDD vs YYYY-MM-DD).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as China Bond Information Network's treasury and other bond yield curves, and the URL containing 'historyQuery' implies a query operation. However, it lacks an explicit verb like 'retrieve' or 'query', making the action slightly implicit. It is clearly distinguished from sibling bond tools that focus on other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific constraint that end_date minus start_date should be less than one year, which guides parameter usage. However, there is no guidance on when to choose this tool over sibling bond tools or the intended scenarios. Usage is implied by the title and date parameters rather than explicitly stated.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and source URL but does not disclose potential behaviors like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the key purpose, followed by the source URL and docstring-style parameter/return info. No fluff, though the URL embedded mid-text slightly disrupts readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with annotations, the description adequately covers what it returns and its parameter. Lacking an output schema, the return description suffices for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter start_date is described as '开始统计时间' (start statistics time), adding meaning beyond the schema's type and default. However, the date format is not explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the resource (中美国债收益率, China-US Treasury yields) and provides the source URL, making it clear this tool fetches yield data. It does not explicitly differentiate from similar bond tools, but the resource 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/5Does 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. The description only states what data is returned, with no mention of when it should be preferred over other bond yield 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?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds a return type (DataFrame) and source URL, but doesn't disclose potential behaviors like data granularity, pagination, or permissions. This is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, URL, and param/return docs. It is well-structured and reasonably concise, though the URL line is not essential for invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param retrieval tool without an output schema, the description gives the source, parameter choices, and return type. It lacks information about output columns or data coverage, but is adequate for basic use. The absence of alternative guidance slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's param docs carry the burden. It specifies symbol as a choice of three Chinese labels and date as year/month, providing meaning beyond bare strings. It doesn't explicitly state the YYYYMM format, but the default suggests it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as Gasgoo automotive sales data with a ranking URL, and parametrizes by enterprise, brand, or model. It lacks an explicit verb like 'retrieve' but is reasonably clear about the resource. It differentiates from siblings by naming Gasgoo and the specific ranking 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/5Does 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 the numerous car_market_* siblings from CPCA. The description only gives a URL and parameters, without exclusions or alternative tool mentions.
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 already declare readOnly, openWorld, idempotent, and non-destructive, so the bar is lower. The description adds the source URL and return type (pandas.DataFrame), which is useful, but it doesn't disclose details like data granularity, date range, or update frequency beyond 'daily'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title, a source URL, and a return type. Every line adds value, no filler. This is a model of efficiency for a simple parameterless function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the essentials: source and return type. However, the naming inconsistency (EU vs. international) could mislead an agent, and the description doesn't explain what columns or metrics are included in the DataFrame, slightly reducing completeness for a data-returning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline of 4 applies. The description correctly documents the return type, and since there are no parameters to explain, nothing further is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns '国际碳情每日行情数据' (international carbon daily market data) from the Shenzhen Carbon Exchange, which is a specific resource. However, the tool name says 'eu' but the description says 'international', creating slight ambiguity about regional scope, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools like energy_carbon_domestic, energy_carbon_bj, etc. No exclusions or alternatives are mentioned, leaving the agent to guess which carbon data source to pick.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds the source URL and return type, but does not disclose characteristics such as data update frequency, columns included, or potential pagination. With annotations covering safety, the extra context is marginal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no unnecessary words. The title, URL, and return type lines each serve a purpose. It is front-loaded with the exchange name and clearly communicates the output type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description provides the source URL and return type but lacks detail about the actual content structure (e.g., what columns or time range the '行情信息' includes). This is minimally sufficient but leaves gaps in understanding what the returned DataFrame will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema confirms no inputs are required. Per the rubric, a baseline of 4 is appropriate; the description does not need to explain parameter semantics, and no ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Guangzhou Carbon Emissions Exchange) and the action (returning market/quote data), with the URL providing provenance. It is distinguishable from sibling tools by naming the specific exchange, though the term '行情信息' is somewhat generic and could be more specific about the type of 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/5Does 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 like energy_carbon_bj or energy_carbon_sz. The description only states what it does, not in which scenarios it is the appropriate choice.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), but no additional behavioral details such as data frequency, update schedule, or scope. This is acceptable for a simple read-only tool, but the description itself adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes the source URL and return type, but it is slightly redundant: the first line and the ':return:' line essentially repeat the same concept. It remains concise and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter nature, rich annotations (read-only, idempotent, non-destructive), and simple DataFrame return, the description is nearly complete. It identifies the data source and return type. However, it does not describe the data shape or columns, which could be useful if the agent needs to interpret the DataFrame, but this is not critical for a no-param retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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. The input schema confirms no parameters, and the description's return mention is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns a fund market management scale trend chart from Eastmoney, which is specific and clear. However, it lacks an explicit verb like 'get' or 'fetch', and the phrase '走势图' is repeated in the return line. It does not distinguish itself from sibling tools such as fund_aum_hist_em or fund_aum_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No mention of whether it covers the entire market, historical range, or how it differs from similar AUM tools. The description only states what it returns, not the context for selecting it.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns data for the current trading day and as a pandas.DataFrame, but does not disclose other behavioral traits like data columns, pagination, or potential latency. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with a clear structure: source, scope, return type. The first line repeats the title, but it is not harmful. Every sentence contributes, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only data retrieval tool, the description provides the essential context: data source URL, what data is returned (all on-exchange funds for current trading day), and return type. It could list columns or edge cases, but given the simplicity and existing annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter syntax. It still adds value by specifying the return type (pandas.DataFrame) and the data scope (current trading day), which is sufficient for a no-parameter data retrieval function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns all on-exchange (场内交易) fund data for the current trading day, with a specific verb and resource. It is distinguishable from sibling fund tools by the '场内交易基金' scope, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 similar fund daily tools (e.g., fund_etf_spot_em, fund_open_fund_daily_em). There are no explicit exclusions or alternatives, so an agent has to infer usage purely from the tool name and category.
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 already declare read-only, idempotent, non-destructive behavior. The description adds that an empty date returns the latest data and that the return is a pandas DataFrame. It does not disclose details like data structure or rate limits, but is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a repetitive breadcrumb and URL, then uses structured param/return docs. It is moderately concise but not front-loaded with a clear, concise purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool without an output schema, the description provides the data source, parameter format, and return type. However, it does not detail the DataFrame columns, whether multiple ETFs are returned, or any quirks, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'date' parameter's meaning (统计日期), format ('20250115'), and default behavior (empty returns latest data). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as SSE ETF product scale data, with a URL and return type indicating it provides ETF fund share data. It implies the tool's purpose clearly, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the data source is the Shanghai Stock Exchange (上海证券交易所), which implies when to use it, but it does not explicitly contrast with alternative tools like fund_etf_scale_szse or state exclusions. Usage context is clear but not fully elaborated.
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 already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the data source URL and return type (pandas.DataFrame), but it does not disclose pagination, data volume, or columns, which would be useful but is not strictly required given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and organized with URL, parameter, and return type sections. However, the exact same Chinese phrase is repeated in the description and in the :return: field, making it slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description provides the source, parameter semantics, and return type. It does not specify expected DataFrame columns, time range, or historical depth, but the title '历史净值明细' communicates the general content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that symbol means '分级基金代码' and recommends ak.fund_money_fund_daily_em() to obtain valid symbol values, adding meaning beyond the bare schema. It does not specify format constraints like six-digit codes, but the example and explanation are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (分级基金净值-历史净值明细) and data source, making it understandable that this returns historical NAV details for graded funds. However, it uses a noun phrase rather than an explicit verb like '获取' or '查询', and it does not explicitly contrast with the sibling fund_graded_fund_daily_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful context that the symbol can be obtained via ak.fund_money_fund_daily_em(), which helps the caller supply a valid parameter. However, it does not state when to use this tool versus similar fund-related functions or mention any exclusions.
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?
The description adds valuable behavioral context beyond the annotations: it explicitly states the interface currently has no data, which is a critical caveat for an agent. It also specifies the return type (pandas.DataFrame) and provides the source URL. Since annotations already cover read-only and non-destructive behavior, the description's additional details earn a solid score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes a redundant title line duplicated in annotations, a lengthy URL that may not be essential for an agent, and a comment-style note. It front-loads the purpose and includes the critical no-data warning, but the structure is fragmented and the URL adds clutter without clear value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with a simple purpose, the description is partially complete: it identifies the ranking type and source and warns about current data unavailability. However, it does not describe the expected columns or structure of the returned DataFrame, and with no output schema, an agent lacks detail on what to expect if data were present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description does not need to explain parameter semantics. The baseline for 0-parameter tools is 4, and the description satisfies this by not omitting any required parameter clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides a ranking of wealth management funds (理财基金排行) from East Money's data center, with a return type of pandas.DataFrame. However, it lacks an explicit verb like 'get' or 'fetch' and does not differentiate itself from the many sibling ranking tools, though the name suggests the specific fund type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The note '该接口暂时没有数据' (this interface currently has no data) implicitly warns that it may return empty results, but it does not name alternative tools or provide context for when the tool is appropriate.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context by specifying the return type (pandas DataFrame) and the data source URL, plus the parameter choices. However, it does not describe potential rate limits, output columns, or behavior with invalid dates/symbols, leaving some gaps beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear title line, a relevant URL, parameter definitions, and a return type. It is front-loaded with the core purpose and follows a consistent structure. No redundant fluff, though the return line '每日分时行情' partially repeats the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter data retrieval tool with no output schema, the description provides the essential purpose and parameter documentation. But it lacks example calls, clarification of the DataFrame structure, and details on date/time formatting or timezone handling. It is adequate for basic use but not fully complete for an agent to invoke correctly in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by listing all 5 parameters with types and enum-like choices (period: 1,5,15,30,60; adjust: '', qfq, hfq). It gives basic descriptions like 'LOF 代码' and '开始日期时间'. However, it does not specify date format expectations, the meaning of 'qfq'/'hfq' (forward/backward adjustment), or clarify that period values are in minutes, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '东方财富-LOF 分时行情' (Eastmoney LOF minute-level market data), specifying the resource (LOF funds) and data frequency (intraday). The name and return type '每日分时行情' further clarify it provides historical minute-by-minute data. It distinguishes from sibling tools like fund_lof_spot_em (spot) and fund_lof_hist_em (likely daily) via the 'min' in the name and the period choices, though it does not explicitly call out differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage through the tool name and parameter choices (period options like '1', '5', '60' for minutes) and the return statement '每日分时行情', suggesting it is for intraday/minute-level historical LOF data. However, it provides no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the source URL, which is useful context, but it does not disclose any latency, pagination, or network requirements beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key information, but it mixes Chinese and English docstring syntax and includes a URL that may not be necessary. Still, it is efficient and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter tool, the description adequately states what is returned (names and types of all funds) and the return type (pandas.DataFrame). It lacks explicit column names but the core information is present, and 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema coverage is trivially 100%. Since there are no parameters to document, the description does not need to add any semantics; the baseline of 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (all funds on Tiantian Fund Network) and the scope (names and types), which distinguishes it from sibling fund tools. However, it lacks an explicit verb, relying on inference that this is a retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other fund-related tools. It does not mention any exclusions, prerequisites, or alternative tools, leaving the agent to infer usage from the name and description.
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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, which cover safety. The description adds the source URL and return type (pandas DataFrame), but no further behavioral details such as data freshness, pagination, or columns, which is acceptable for a simple parameterless query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a source URL and a return type line. It is efficient and front-loaded, though the format is somewhat technical and could be more readable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with annotations covering safety, the description conveys the data source, the category (trading parameters contract info), and the return type. While it does not enumerate columns, the simplicity of the tool makes this largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description confirms no inputs are needed and returns a DataFrame, which is sufficient for parameterless invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (DCE contract info under trading parameters) and names the exchange in the title, distinguishing it from sibling tools for other exchanges. Although it lacks an explicit imperative verb like 'list' or 'get', the ':return:' line and URL make the retrieval purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The name and URL imply DCE-specific usage, but there is no explicit mention of when to choose this over futures_contract_info_cffex, futures_contract_info_czce, etc.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is covered. The description adds the source URL (http://www.gfex.com.cn/gfex/hyxx/ywcs.shtml) and the return type (pandas DataFrame), providing context about data provenance and output format. However, it does not disclose any potential rate limits, data freshness, or specific fields returned, leaving some behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three lines including the title, URL, and return type. Every piece of content serves a purpose: the URL identifies the official data source, and the return type informs the agent of the output structure. There is no fluff or redundant repetition, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, read-only, no output schema), the description is borderline adequate. It names the data source, what it queries (trading parameters summary), and the return type. However, it does not enumerate the specific columns or data fields that would be in the DataFrame, nor does it mention any caveats like whether it includes only current contracts or historical data. This leaves meaningful gaps for an agent deciding if this tool meets a user's request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100% with an empty properties object. No parameter documentation is needed. The description does not add parameter semantics, but for a no-parameter tool this is not a gap, so the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '广州期货交易所-业务/服务-合约信息' (Guangzhou Futures Exchange - Business/Service - Contract Information) and ':return: 交易参数汇总查询' (Trading parameters summary query), indicating a query operation for contract information of the GFEX. This is specific enough to distinguish it from similar exchange-specific tools, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the sibling tools for other exchanges (e.g., futures_contract_info_cffex, futures_contract_info_czce). It does not state any exclusions, prerequisites, or scenarios where this tool is preferred. The only differentiator is the exchange name in the title and tool name, which is implicit rather than explicit guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that the return type is pandas.DataFrame and includes a source URL, providing some context beyond the annotations. However, it does not disclose any additional behavioral traits such as update frequency or data limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, containing a title, a URL, and return type information in two lines. No unnecessary words, though the phrase '期货交易费用参照表' is repeated in the title and return description, which is mildly redundant but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, no-parameter tool, the description is fairly complete. It identifies the data source (openctp), provides a URL for details, and states the return type. The lack of an output schema is mitigated by the clarity of the 'fee reference table' concept, and the annotations cover the operational safety aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 schema is empty (100% coverage), and there is nothing for the description to explain. The description appropriately focuses on the output rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides an 'openctp 期货交易费用参照表' (openctp futures trading fee reference table) with a source URL. While it lacks an explicit verb, the resource and its purpose are unambiguous. It distinguishes from sibling tools like futures_rule or futures_settle by focusing specifically on fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of scenarios where this fee reference table is appropriate, nor any exclusions or comparisons to other futures-related tools. The description only states what it is, not when to select it.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety profile is covered. The description adds that the return is a pandas.DataFrame and that symbol codes can be discovered via another function, but does not detail column names, date ranges, or pagination behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, starting with a clear title line and source URL, followed by parameter/return documentation. Every sentence contributes useful information, though the URL example could be integrated more elegantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values. It identifies the return as historical market data and a DataFrame, but lacks specifics on columns, date range, or data granularity. The annotations cover risk characteristics, so overall completeness is adequate for a simple one-parameter tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'symbol' is a product code and points to futures_global_spot_em for obtaining all valid codes. This adds meaning beyond the schema's bare default value, but it does not explain the format (e.g., what 'HG00Y' represents or how it maps to the URL example).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical market data for international futures from Eastmoney, with a specific source URL and data type (pandas.DataFrame). It distinguishes itself as 'international futures' history, which helps separate it from domestic futures 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete method to obtain valid symbol values by referencing ak.futures_global_spot_em(), giving implicit guidance on when to use this tool (when you need historical data for international futures). However, it does not explicitly state when not to use it or compare to alternative futures history 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the return is a pandas.DataFrame with market data, which is useful context. However, it does not disclose additional behavioral traits such as refresh frequency or data scope, but the annotation coverage lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured like a docstring, with source, URL, return description, and return type. Every line provides some context. The URL adds minor redundancy but is harmless. No fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only spot data tool, the description is reasonably complete: it states the source (East Money), the market category (international futures), and the return format (pandas DataFrame). It lacks explicit detail on columns or data coverage, but given the minimal complexity and good annotations, it is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the schema fully defines the input. With no parameters to explain, the description does not need to add param semantics. The baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving international futures market quotes from East Money (东方财富网-行情中心-期货市场-国际期货), and states the return is market data (行情数据). While it lacks an explicit verb like 'get', the meaning is clear. It distinguishes from historical futures tools by including 'spot' in the name and focusing on the quotes center, though it does not explicitly contrast with sibling tools like futures_global_hist_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only gives a source URL and return type, with no mention of scenarios, exclusions, or related tools. An agent has to infer usage solely from the name and context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the source URL and return type, but does not disclose behavioral details such as date format requirements, symbol format conventions, or potential error cases. It adds some contextual value but not rich behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a source URL, parameter list, and return type in a clean, structured format. Every line is informative, and there is no redundant prose or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only states that the return is a pandas DataFrame of market data, without column details. It also lacks explicit date and symbol format guidance, though the default values provide hints. The annotations and parameter list provide a baseline, but the description is not fully complete for a tool with four parameters and no schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter semantics. It provides meaningful Chinese labels for all four parameters, including the allowed period choices ('daily', 'weekly', 'monthly'). However, it omits details like the expected date format and symbol code conventions, which are only revealed through the default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving futures market data from Eastmoney, includes the source URL, and lists the key parameters for symbol, period, and date range. It clearly conveys the resource and operation, though it lacks an explicit verb like 'retrieves' or 'fetches'. It is distinguishable from sibling futures history tools by the Eastmoney source and the combination of parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling futures history tools, and it does not mention alternatives or exclusions. The intended use is only implied by the tool name and parameter list, which is insufficient given the large number of similar 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the return type (pandas.DataFrame) and the data source (99qh.com), but does not disclose other behavioral traits such as network dependence, rate limits, or response format nuances. Given the annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, well-formatted as a docstring, and includes only essential information: source URL, parameter semantics, and return type. It is front-loaded with the tool's purpose and avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not disclose the structure of the returned DataFrame (e.g., columns, time range). It also lacks information about data update frequency or coverage, which could be important for an agent. However, the tool is relatively simple, so the moderate completeness is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the symbol parameter, so the description's explanation of symbol as 'the specific product variety corresponding to the exchange' with an example (DCE soybean) adds crucial meaning. However, it does not provide a comprehensive list or method for discovering valid symbols.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing bulk commodity inventory data from 99qh.com, with a specific URL and a parameter for commodity symbol. However, it lacks an explicit verb like 'get' or 'retrieve', and it does not differentiate from sibling tools such as futures_inventory_em, though the source is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or alternative tools. It only describes the parameter and return type, implying basic usage but not offering context for selection.
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 already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safe read nature is covered. The description adds the source URL and date flexibility, but doesn't disclose return format or any potential quirks. This adds some value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes the essential information: function purpose, source URL, parameter format, and return type. The multiple date format options could be seen as slightly verbose, but they are valuable for users to know.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with one optional parameter, the description covers the main needs: source, parameter format, and default. However, it doesn't describe the data structure beyond saying pandas.DataFrame, which is minor 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the date parameter, but the description thoroughly documents the date parameter's accepted formats (YYYY-MM-DD, YYYYMMDD, datetime.date) and default behavior. This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves settlement parameters from the Zhengzhou Commodity Exchange (CZCE) with a specific URL, which is a specific verb+resource. It doesn't explicitly distinguish from sibling tools like futures_settle_ine or futures_settle_shfe, but the exchange name in the title and description makes it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving CZCE settlement parameters by date, with a default to current trading day. No explicit when/when-not or alternatives are stated, but the domain-specific naming and date parameter provide implied 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?
The description adds no behavioral traits beyond the annotations. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description merely repeats the data source URL and return type without disclosing rate limits, data freshness, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with title, source URL, and param/return sections. The first line duplicates the annotation title, but the overall size is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 conveys the exchange, data type, and return shape (DataFrame). However, without an output schema, it doesn't specify the DataFrame's columns or handle edge cases like non-trading dates, so completeness is modest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents date as '交易日' (trading day), which adds semantic meaning beyond the schema's bare type/default. However, it doesn't specify the expected format (e.g., YYYYMMDD) beyond the default value, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (SGX derivatives historical settlement prices) and specifies the output: all futures products' historical settlement prices for a given trading day. It distinguishes from exchange-specific siblings by naming 新加坡交易所 (SGX). However, it lacks an explicit verb like 'get' or 'list', relying on the return statement to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets context by naming the exchange (新加坡交易所) and data type (historical settlement prices), making it obvious when to use this tool for SGX data. It does not explicitly mention alternatives or exclusions, but the exchange name differentiates it from the many other futures_settle_* siblings.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds context by providing the source URL and specifying the return type as a pandas.DataFrame. However, it does not disclose any additional behavioral traits such as data freshness, network dependencies, or error handling, which would be valuable. Thus it earns a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact, consisting of a data-path string, a URL, and a return annotation. It is front-loaded with the essential product name '人民币外汇远掉报价'. However, the title-like first line duplicates the annotation's title, and the return type could be integrated into a single sentence. Still, no wasted sentences, so a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides the core essentials: the data source, the type of data, and the return format. It could be more complete by mentioning the data's scope (e.g., real-time vs. historical) or typical columns, but given the simplicity, a 4 is reasonable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, and the schema has 100% coverage (empty properties). The description does not need to explain parameters, and it adds meaning by stating the return type and data source. With zero parameters, a baseline of 4 is appropriate, and the return-type note is a useful addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns '人民币外汇远掉报价' (RMB FX forward swap quotes) from the China Foreign Exchange Trade System, which is a specific data product. However, it lacks an explicit verb like 'get' or 'fetch', and the naming is somewhat implicit. It does distinguish from related siblings like fx_spot_quote by specifying '远掉' (forward/swap), so it earns a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as fx_spot_quote, fx_pair_quote, or fx_c_swap_cm. It simply states the data source and return type, with no indication of use cases or exclusions. This is a clear gap.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame), which provides modest behavioral context beyond the annotations. However, it does not disclose details like update frequency, pagination, or data completeness, so it does not go far beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the main phrase front-loaded followed by a URL and return type. Every line earns its place except perhaps the redundant :return and :rtype lines, which repeat the implied output. Slightly more structure (e.g., a clear verb) would improve clarity, but it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with rich annotations (readOnly, openWorld, idempotent, non-destructive), the description is nearly sufficient. It names the specific data set (all CNI indices of the most recent trading day), provides a source URL, and states the return type. It does not explain the exact columns or data format, but given no output schema and the tool's simplicity, the omission is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is vacuously 100% covered. Per the rubric, a no-parameter tool gets a baseline of 4 because there is no parameter semantics to clarify. The description adds no parameter-related content, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('国证指数' / CNI indices) and scope ('最近交易日的所有指数' / all indices of the most recent trading day), which aligns with the name 'index_all_cni'. It includes a source URL and return type, which helps distinguish it from sibling index tools like index_detail_cni or index_hist_cni, though it lacks an explicit verb like 'fetch' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 conditions like 'for all CNI indices' or exclude other index-related tools. The sibling list contains many index tools, but the description offers no differentiation or selection criteria.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds the source URL and states that the return is a pandas.DataFrame, but it does not disclose additional behavioral traits such as pagination, data coverage, or dependencies. The note about obtaining the date from another interface (ak.index_analysis_week_month_sw) is a useful contextual hint, but overall the description adds modest value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title, a URL, and parameter/return docstrings. Each line serves a clear purpose, and there is no redundant filler. The only minor issue is that the Chinese title and URL might be unnecessary for execution, but they add source context. Overall, the structure is clean and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The complete context is insufficient. There is no output schema, so the description should detail the DataFrame's columns or content, but it merely states '指数分析' (index analysis), which is tautological. It also does not explain how to choose valid dates for weekly data or how this tool differs from its siblings, leaving the agent uncertain about the output structure and usage boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions, leaving a 0% coverage, so the description is the sole source of parameter meaning. It lists the exact allowed values for symbol (e.g., '市场表征', '一级行业', '二级行业', '风格指数') and specifies the date format with an example (20221104). This compensates well for the schema gap, though the date semantics are somewhat vague (e.g., what date represents for a weekly report).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the title '申万宏源研究-指数分析-周报告' (Shenwan Hongyuan Research Index Analysis Weekly Report), which clearly identifies the tool's purpose as retrieving weekly SW index analysis data. The parameter list and return type further clarify the function. However, it does not explicitly contrast itself with sibling tools like index_analysis_daily_sw or index_analysis_monthly_sw, so it only earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for weekly reports through its title and name, but it offers no explicit guidance on when to use it versus other index analysis tools. There are no mentions of alternatives, exclusions, or prerequisites. The only usage hint is the '周报告' label, making this an implied usage rather than explicit direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the return type (pandas.DataFrame) and a data source URL, but does not mention network dependencies, update frequency, or any other behavioral traits. It neither contradicts nor significantly enriches beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, containing only three lines: the title, the URL, and the return type/format. Every part adds value without redundancy. This is an appropriate size for a zero-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless read-only tool, the description is moderately complete. It identifies the data source, provides a reference URL, and the return type. However, it lacks detail about the DataFrame's columns, index, units, or the period covered, which could be important for an agent to assess the data's relevance. Since no output schema exists, the description carries the full burden for return-value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the baseline score is 4. The description adds no parameter information (there is nothing to describe), which is acceptable given the empty schema. No additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '财新数据-指数报告-资本投入指数' (Caixin Data – Index Report – Capital Input Index), clearly identifying the resource. The return type 'pandas.DataFrame' and URL reinforce that this tool provides capital input index data. It doesn't explicitly distinguish itself from sibling Caixin index tools like index_nei_cx, but the name and description are specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 index_nei_cx or other index_*_cx tools. There are no explicit usage conditions, exclusions, or context on when this index is relevant. The usage is only implied by the resource name.
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 already cover safety traits (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds minimal behavioral context: the source URL and the return type (pandas.DataFrame). It does not disclose data content, granularity, or any unique behavioral characteristics beyond those signals, but this is sufficient given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: it leads with the tool's purpose, then the source URL, then return metadata. Every element is relevant and there is no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple parameterless tool: it tells the agent what it returns (a DataFrame with the Digital Economy Index) and its source. However, it does not describe the DataFrame's columns or data granularity, and there is no output schema to fill that gap. This is a clear limitation, but the description is still usable for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is empty and the description's main contribution is the return type (:rtype: pandas.DataFrame) and the source URL. With 0 parameters, the baseline is 4, and the description adds value by specifying the output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (Digital Economy Index) and the source (Caixin Data) with a URL, and the :return: tag indicates it returns the index. However, it lacks an explicit verb like 'retrieve' or 'get', so it reads more like a title than a clear action statement, though the intent 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/5Does 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 alternative index tools. The description simply repeats the name and provides a URL and return type. It neither mentions alternatives nor provides exclusion criteria, leaving the agent to infer usage solely from the tool name.
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 already indicate readOnlyHint=true and destructiveHint=false, so the tool is a safe read operation. The description adds that it returns a pandas DataFrame and provides the source URL, which is useful context. However, it does not disclose any limitations on date range, pagination, or data scope beyond the parameter, so it adds only moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes essential info: name, source URL, parameter, return type. It is structured like a docstring, which is easy to parse. The URL line could be integrated more cleanly, but overall it is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema, good annotations), the description is nearly complete. It tells the user what data is returned (historical samples as DataFrame), how to identify the index (symbol code), and where the data comes from. The only missing piece is explicit mention of null/empty behavior or default interpretation, but this is not critical for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (symbol) with no description in the schema itself (coverage 0%). The description compensates with a clear docstring: ':param symbol: 指数代码; "399001"' and ':type symbol: str', including an example value. This fully explains the parameter's meaning and format, which is exactly what the agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves historical sample details for a CNI index, with a specific URL and example index code. It distinguishes itself from sibling tools like index_detail_cni by the term '历史样本' (historical samples) in both the title and description, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus similar ones like index_detail_cni or index_detail_hist_adjust_cni. The description implies historical data usage via the URL and naming, but lacks clear context or exclusions. Given the large set of similar index tools, more specific usage guidance is needed.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and side effects. The description adds the data source URL and parameter choices, but does not disclose response details, data freshness, or failure modes. Given the annotations, the description provides moderate additional context but not rich behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and follows a standard docstring structure with title, URL, parameter, and return sections. It front-loads the index name and source. Minor redundancy exists with the return line repeating the index name, but overall it is well-organized and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only index tool with one parameter and no output schema, the description includes the source URL, parameter choices, and return type (pandas.DataFrame). It lacks contextual details such as data history or column descriptions, but given the tool's simplicity and the presence of strong annotations, this is largely complete. A brief note on data frequency or time range would elevate it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property description for 'symbol' (0% coverage), but the description explicitly defines valid values as {'月度', '季度'} and its type. This is essential information that compensates for the schema gap. It could further elaborate on the meaning of the values (e.g., monthly/quarterly index data) but is already helpful beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the Zhejiang Province Pollution Discharge Right Trading Index (浙江省排污权交易指数) and provides a source URL (https://zs.zjpwq.net). While it lacks an explicit verb like 'get' or 'query', the purpose is evident and distinct from sibling index tools by region and index type. A verb would make it clearer, but the naming and context suffice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only documents parameter choices (月度/季度) and the return type, with no mention of exclusions, prerequisites, or different use cases. For a data retrieval tool among many similar index tools, this lack of usage differentiation is a notable gap.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the return type (pandas DataFrame) and source URL, but does not disclose potential quirks like rate limits, data granularity, or available date ranges. This is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: title, URL, param definition, return type. Every line adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple historical data tool, the description covers the purpose, parameter, and return type, but lacks details about the output DataFrame columns, date range, or usage context. With no output schema specified, more detail on the return structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a default value for 'symbol' with no description. The description compensates by explaining that symbol is an index name and directs to ak.index_global_name_table() to discover valid values. This is useful and goes beyond schema, though it could include examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this provides historical market data for global indices from Sina Finance, with the resource identified by the URL and title. However, it lacks an explicit verb like 'retrieve' or 'fetch', instead using a noun phrase '环球市场历史行情'. It distinguishes from siblings via the 'sina' source in the name and URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a prerequisite for the symbol parameter (obtained via ak.index_global_name_table()) but does not mention when to choose this tool over alternatives like index_global_hist_em. No exclusions or alternative tool references are given.
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 already cover safety (readOnly, non-destructive). The description adds useful context about returning a pandas DataFrame and the source URL, but does not disclose other behavioral specifics such as pagination, data freshness, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes standard docstring elements (URL, :return:, :rtype:). It is front-loaded with the title and avoids redundancy, though the format is slightly non-standard for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description adequately conveys the data source, what data is returned, and the return type. The absence of an output schema makes the return-type note valuable. It does not discuss edge cases or selection criteria, but that is not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics (vacuously). The description correctly omits parameter details, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (new economy industry entry average salary from Caixin Data) and the return type. It is specific enough to distinguish from sibling index tools like index_nei_cx, though it lacks an explicit verb like 'returns' or 'fetches'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 names the data source and URL, with no mention of exclusions, prerequisites, or comparisons to sibling index 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?
Annotations already convey read-only, idempotent, open-world behavior. The description adds the source URL and return type (DataFrame), which is useful but does not go further into data scope, update frequency, or other behavioral traits. It does not contradict annotations and adds minimal context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the source title, URL, and return type. Every line serves a purpose with no redundancy or filler. The structure is linear and front-loaded, placing the identifying title first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides the essential return type (DataFrame) but lacks details about the dataset's columns, time range, or whether it is a time series or single snapshot. Without an output schema, such information would help, but the description is minimally sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description has no parameter information to add, and none is needed. Baseline for 0 parameters is 4, and no deduction applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (新动能指数 / New Kinetic Energy Index) and states it returns a pandas DataFrame. The verb is implicit (get/fetch) but the ':return:' line makes the purpose evident. It distinguishes from similar index_*_cx tools by naming the specific index, though it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios, exclusions, or relationships to similar index tools like index_nei_cx or index_bei_cx. The description only implies usage through its title and return type, with no explicit context.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so safety is covered. The description adds the data source URL and the return type (pandas.DataFrame), which provides some context beyond annotations. However, it doesn't disclose potential rate limits, data coverage, or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with source URL, return value, and return type. However, the first line repeats the annotation title exactly, which is redundant. The URL may be of limited use to an AI agent. Overall, it is efficient but not perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description provides the essential information: what data is returned and in what format. It lacks details about the data's structure or interpretation, but given the tool's simplicity and the presence of annotations, it is mostly complete. An output schema is absent, so the return type mention partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the tool has zero parameters and the schema is empty, there is no parameter semantics to explain. Per the baseline for 0 parameters, a score of 4 is appropriate. The description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the China New Economy Index (中国新经济指数) from Caixin, with the ':return:' field specifying the returned data. However, it lacks an explicit verb like 'fetch' or 'get', making it slightly less direct than ideal. The specific index name distinguishes it from sibling index 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/5Does 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. With many sibling index_*_cx tools, the description does not explain what makes this index unique or when it should be preferred. No exclusions or alternative tool mentions 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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds minimal context: it specifically returns the latest constituents and points to the csindex.com.cn source. However, it does not disclose data freshness, column details, or any potential caveats beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes the essential components: source URL, parameter documentation, and return type. It is reasonably structured despite being a free-form docstring, with no redundant information beyond what is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description provides adequate context: source, parameter meaning, return type, and the 'latest' qualifier. It does not describe the DataFrame columns or limitations, but given the simplicity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a default value, but the description explains that symbol is an index code and suggests using ak.index_stock_info() to obtain it. This adds meaningful semantics beyond the schema, making it easier for the agent to understand and populate the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches constituent stocks from the CSI index website with a specific URL, and it returns the latest index constituents. The resource and scope are clear, and the source URL differentiates it from sibling tools like index_stock_cons_sina, 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 Guidelines2/5Does 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 index_stock_cons, index_stock_cons_sina, or index_stock_cons_weight_csindex. The only hint is the source URL, but there is no explicit when-to-use or when-not-to-use instruction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and the pandas.DataFrame return type, which is useful context. However, it does not disclose the index composition, update frequency, date coverage, or columns, so behavioral transparency is only partially enhanced beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title line, source URL, and return type/intent lines. Every element adds useful information and there is no filler or repetition, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description gives the source and return type but omits details about the returned dataset's structure, periodicity, units, or update schedule. Since the output schema is absent, a bit more detail about what the DataFrame contains would make the tool more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter information to supplement. Per baseline for 0-parameter tools, a score of 4 is appropriate; the description doesn't need to elaborate on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning the China Sugar Index (中国食糖指数) from Mutian Technology's data center and includes the source URL and return type. While it lacks an explicit verb like 'retrieves' or 'fetches', the title and `:return:` docstring make the purpose reasonably clear. It is distinguishable from sibling sugar quote tools by naming the index rather than quotes, though it doesn't explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as index_inner_quote_sugar_msweet or index_outer_quote_sugar_msweet. There are no exclusions, prerequisites, or context cues beyond the source and return type, so an agent receives little help in choosing this tool over related ones.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict these. It adds context by specifying the source URL and the pandas DataFrame return type, but it does not disclose behavior such as data freshness, rate limits, or error handling. Given the annotations cover the safety profile, the extra context is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a title, a source URL, and a clear param/return docstring. Every line serves a purpose with no redundancy. It is appropriately sized for a simple single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple quote tool, the description provides the essential parameter and return type, but the return value is described only as '美股指数行情' (US stock index quotes) without details on the DataFrame structure, columns, or whether it is real-time, delayed, or historical. Since there is no output schema, the description could be more explicit about the data content and format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema for 'symbol' has no description and no enum, so the description compensates by documenting the allowed values: '.IXIC', '.DJI', '.INX', '.NDX', and the type (str). This is valuable and goes beyond the schema. However, it does not explain the meaning of each symbol (e.g., which index they represent), which would be additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '新浪财经-美股指数行情' (Sina Finance US stock index quotes) and includes a URL for Sina's US stock index pages, indicating the resource and scope. It distinguishes from sibling tools by specifying US stock indices from Sina rather than global or other exchange indices, though it lacks an explicit verb like 'fetch' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternative tools for related data (e.g., historical data or other index providers). The only intended use is implied by the name and the symbol parameter.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type but does not disclose other behavioral traits such as data coverage, update frequency, or column details. With annotations present, this is adequate but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the source and subject. It includes the URL, return type, and description in two short lines with zero wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data fetch, the description gives the essential information: source, subject, and return type. However, it lacks details about the actual data content (e.g., columns, date range) and does not differentiate from the near-identical sibling macro_bank_australia_interest_rate. With no output schema, the description should do more to explain the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has 100% coverage (empty properties). The description mentions the return type (pandas.DataFrame) but adds no parameter semantics because none exist. For zero-parameter tools, the baseline is 4, and the description provides no conflicting or missing info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Australia's central bank interest rate decisions from East Money, including a specific URL and return type. However, it doesn't differentiate from the closely named sibling macro_bank_australia_interest_rate, so the purpose is clear but not distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 provides no context about use cases, prerequisites, or exclusions, and the sibling macro_bank_australia_interest_rate appears overlapping without clarification.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so safety is well-covered. The description adds no behavioral context such as data coverage, update frequency, response size, or limitations. The only additional info is the URL and return type, which 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a title, URL, and return type note. It is front-loaded with the key information and contains no verbose filler. However, the reliance on a label-style title and the inclusion of a URL that isn't essential for tool invocation prevent a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description states the return type (DataFrame) and the metric (CPI quarterly rate), providing core context. It lacks details about the historical range, column names, units, or data granularity, which are relevant for an agent to fully understand the result. This is minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing to explain. The baseline for 0-param tools is 4. The description doesn't need to elaborate on parameters, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the data source (东方财富/Eastmoney), country (Australia), indicator (Consumer Price Index), and frequency (quarterly). This specific noun-phrase style makes the tool's purpose unmistakable and clearly distinguishes it from siblings like macro_australia_cpi_yearly and macro_australia_ppi_quarterly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is simply a title and return type, with no mention of exclusions, related tools, or specific use cases. The usage is only implied by the name, not articulated.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is covered. The description adds context by specifying the data range, source URLs, return type (pandas Series), and units (%), which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core purpose. It includes necessary details like data range and return type, though the inclusion of raw URLs adds some noise. Overall, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is sufficiently complete: it states the data source, time range, return type, and units. There is no output schema, so the description appropriately covers the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 correctly does not attempt to explain parameters, and the schema coverage is 100% (vacuously).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Swiss central bank interest rate decision report, with a specific date range and return format (current value in %). It implies a retrieval operation, but lacks an explicit verb like 'get' or 'fetch', so it doesn't fully meet the 'specific verb+resource+scope' criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 what it is, without mentioning any exclusions or comparing to sibling tools like other central bank interest rate functions.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating read. The description adds that the return type is a pandas.DataFrame and the data is core CPI yearly, which is useful but minimal. It does not disclose potential caveats such as data availability, update frequency, or formatting specifics, but this is partially mitigated by the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of a title, source URL, and return annotations. It is concise and front-loaded with the key information. However, it is somewhat fragmented and reads more like a docstring fragment than a polished description, and the title line repeats the tool name. Still, no words are wasted, and the URL provides actionable context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only data retrieval tool with strong annotations, the description covers the essential points: data source, geographic focus, metric type, frequency, and return type. There is no output schema, so the description's mention of 'pandas.DataFrame' partially fills that gap, though column details are not provided. Given the simplicity of the tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there are no parameter semantics to explain. Per the scoring guide, a baseline of 4 is appropriate when there are no params. The description does not need to compensate for any missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Canada's core consumer price index yearly rate from Eastmoney, with the specific resource named in both the title and body. While it lacks an explicit verb like 'fetch' or 'get', the name and context make the action unambiguous. It is distinct from sibling tools like macro_canada_cpi_yearly by explicitly stating 'core' and 'yearly'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related alternatives such as macro_canada_cpi_yearly or macro_canada_core_cpi_monthly. The description only states the data source and return type, leaving the agent to infer the appropriate context. There are no exclusions, prerequisites, or alternative references.
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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, lowering the burden on the description. The description adds the source URL and return type (pandas DataFrame), which is useful, but it does not disclose additional behavioral traits such as data freshness, column structure, or any quirks of the Eastmoney source. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, containing only the title, URL, and return annotations. It wastes no words, but the formatting is somewhat fragmented, with line breaks separating elements rather than flowing prose. Still, it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only tool with no parameters and no output schema, the description provides the essential context: source (Eastmoney), the specific indicator (Canada trade account), and the return type (DataFrame). It lacks details about the exact columns or date range, but that is likely acceptable for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is effectively 100% covered (empty schema). The description correctly provides no parameter details, and the baseline of 4 applies since there is nothing to explain. No additional meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Canada trade data from Eastmoney) and distinguishes it from sibling trade tools by country. However, it lacks an explicit verb like 'get' or 'retrieve', relying instead on the ':return:' annotation to imply data retrieval. The URL and data type make the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternative trade tools such as macro_uk_trade or macro_usa_trade_balance. The description only states the source and data type, leaving the agent to infer usage context from the tool name alone. No exclusions or alternative recommendations 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the data range and return type (pandas.DataFrame), which is useful context beyond the annotations, but it does not disclose additional behavioral traits such as pagination, column details, or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing the essential information in the first line. The URL and return docstring add useful references without excessive verbosity, though the format is somewhat unstructured and mixes prose with docstring elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only tool with no parameters or output schema, the description provides the data range, source URL, and return type, which is adequate for an agent to understand what the tool returns and its coverage. It does not specify column names or exact data structure, but for this simple use case, the information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description is not required to explain parameters. The description includes return type and data range, which compensates for the lack of an output schema and adds value beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing China monthly CPI data with an explicit date range (19960201-present). This distinguishes it from the yearly CPI sibling tools, though it lacks an explicit verb like 'retrieve' or 'get', making it slightly less clear as an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_china_cpi_yearly or macro_usa_cpi_monthly. The sibling tools are not referenced, and the description provides no context for selection or exclusion.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which cover the safety profile. The description adds that it returns a pandas DataFrame and includes a source URL, but does not disclose additional behaviors such as data coverage, frequency, or potential errors. This is acceptable for a simple read-only fetch but adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, URL, and return type. Every line earns its place, and the key information is front-loaded. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description names the indicator and return type, but without an output schema it lacks details about the DataFrame's columns, frequency, units, or date range. An agent may not know if the data is a time series or a single value. This is a meaningful gap for a tool with no other structured output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and there is nothing to explain. The baseline for 0 parameters is 4, and the description does not need to compensate for any missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as China urban fixed asset investment data from East Money (东方财富), and the ':return:' line indicates it returns this data. It does not use an explicit verb like 'get' or 'retrieve', but the meaning is unambiguous given the docstring format. It differentiates from siblings by naming a specific economic indicator, though it does not explicitly contrast with other macro 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool, what alternatives exist, or any exclusions. An agent would have to rely solely on the tool name to infer its purpose relative to the many similar macro_china_* siblings.
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 already indicate read-only, idempotent, and non-destructive behavior. The description adds the data range and return type (DataFrame), but does not disclose additional behavioral nuances like column structure, pagination, or source specifics beyond the URL. It provides a minimal amount of extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with no wasted words, but it is under-specified. The inclusion of the source URL and the :return: pseudo-docstring provide some structure, yet the lack of essential detail (e.g., what columns or data fields are returned) makes it more of a stub than a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description carries the burden of explaining what the returned DataFrame contains. It only mentions 'margin trading report' and a data range, omitting any information about the columns, rows, or expected content. This is insufficient for an agent to know what to do with the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is trivially complete. The baseline for 0 params is 4, and the description does not introduce any confusing parameter-related information. There is nothing to compensate for, so the baseline stands.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the Shanghai margin trading report ('上海融资融券报告') with a specific data range. It distinguishes from sibling tools like macro_china_market_margin_sz (Shenzhen) and stock_margin_sse (which is a different margin report). The resource and scope are 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/5Does 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_margin_sse or macro_china_market_margin_sz. It only states the data range, without any context on selection criteria, prerequisites, or comparison with similar 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the data range, source URL, and return type (pandas.DataFrame), but does not disclose additional behavioral traits such as update frequency, rate limits, or pagination. Since annotations cover the core safety aspects, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three short pieces of information: the report name, data range, source URL, and return type. Each line serves a purpose, though the structure is a bit fragmented (with a raw URL and an explicit ':return:' line). For a simple tool, this is acceptable and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description provides the essential facts: what the report contains (Shenzhen margin trading), the date range, the data source URL, and the return type. It does not mention data frequency or specific columns, but given the simplicity of the tool and the presence of annotations, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, and the input schema is an empty object. The description does not need to explain parameter semantics, and there is no parameter information missing. The baseline of 4 for zero-parameter tools is appropriate because the schema fully covers the parameter space, and the description adds clarity about the return type and data range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '深圳融资融券报告' (Shenzhen margin trading report) and specifies the data range (from 20100331 to present). It distinguishes itself from likely sibling tools like macro_china_market_margin_sh by region. However, it lacks an explicit action verb such as 'retrieves' or 'fetches', relying on the noun phrase to convey 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/5Does 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 specifically for Shenzhen data or refer to the Shanghai counterpart. The description only states what the report is and gives a source URL, with no contextual advice for selection.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds the data range (20160101 to present) and the return type (pandas.DataFrame), which are useful behavioral details. However, it does not disclose other behaviors such as update frequency, data source caveats, or column structure, so the added value 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the key purpose. It includes a source URL and explicit return type annotations. There is minor redundancy (the phrase '中国官方非制造业 PMI' appears twice), but overall it is appropriately sized and structured with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (no parameters, no output schema), the description covers the essentials: what data is returned, the date range, and the return type (pandas.DataFrame). It also provides a source URL for verification. It could mention more about the DataFrame's columns or update frequency, but for a zero-parameter data retrieval tool, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description adds context by stating the data range is from 20160101 to present, implying no user-specified date filtering is available. This is a useful semantic detail beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: China's official non-manufacturing PMI, with a specific date range (from 20160101 to present). The term '非制造业 PMI' differentiates it from manufacturing PMI siblings, though it lacks an explicit verb like 'get' or 'fetch' and does not 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 Guidelines2/5Does 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 sibling tools like macro_china_pmi or give any context about suitable use cases, prerequisites, or exclusions. The only implied usage is for non-manufacturing PMI data, but this is not explicit.
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?
The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the return type (pandas.Series), source URLs, and the data range, which provides some context beyond the annotations. However, it does not disclose any additional behavioral traits such as potential rate limits, update frequency, or specifics about the returned series.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the essential information: the title, data range, source URLs, and return type. It is not overly verbose, though the title is repeated from the annotation and the docstring formatting could be cleaner. Overall, it earns its place without excessive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only data retrieval tool, the description covers the data range, source URLs, and specifies the return type as pandas.Series. It does not detail the index or units, but the name 'CPI MOM' and the rtype provide sufficient context. Since there is no output schema, the description's inclusion of the return type is valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so the baseline is 4. The description correctly implies that no inputs are needed. With no parameters to document, the description does not need to add parameter semantics, and the schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the Eurozone CPI month-over-month report, with a specific data range from 19900301 to present. The name itself distinguishes it from sibling tools like macro_euro_cpi_yoy, and the return type indicates it returns a data series. However, it lacks an explicit action verb such as 'get' or 'list', relying on the noun phrase and docstring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus other macro indicators or CPI tools. It only states the data range and provides source URLs, with no mention of alternatives, exclusions, or specific scenarios where this tool is appropriate.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds the data range, source URL, and return type (pandas.DataFrame), which are useful but do not disclose any side effects, auth requirements, or rate limits. This is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, with one sentence of content plus a URL and docstring. The first sentence is redundant with the annotation title, but the additional source and return type make it efficient. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only data retrieval tool, the description provides the key details: indicator (Eurozone quarterly GDP YoY), date range, source URL, and return type. No output schema exists, but the return type is specified, making it complete enough for an agent to understand what will be returned without needing to configure anything.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the input schema is empty, so there is no parameter-specific documentation needed. The description adds no parameter details because none exist, matching the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Eurozone quarterly GDP YoY report with a specific date range, which distinguishes it from other macro_* siblings. However, it lacks an explicit action verb (e.g., 'get' or 'retrieve'), relying on the ':return:' docstring to imply data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only states the data range and source URL, with no mention of alternative tools, exclusions, or conditions under which this tool is preferred.
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 already declare the tool as read-only, idempotent, and non-destructive, so the description doesn't need to repeat these. It adds data range and source URLs, which is useful, but doesn't disclose any additional behavioral traits such as update frequency or data limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes a couple of source URLs that might be useful for reference, though not strictly necessary. It front-loads the core purpose and return type, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter data retrieval tool, the description adequately states the data range, return type, and metric. Without an output schema, it would benefit from noting whether it returns the full historical series, but the data range implies this. Overall it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is trivially fully covered. The description doesn't need to explain parameters, and there are none to add meaning to. Given the zero-parameter baseline of 4, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the Eurozone industrial production month-over-month report ('欧元区工业产出月率报告') with a specific metric ('今值(%)'). The name and description align, and it's distinct from sibling macro_euro_* tools that cover different 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the many other macro economic indicators (e.g., macro_euro_cpi_mom). It simply states what it returns without context on alternatives or use cases.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context about the data range, return type (pandas.Series), and value meaning (今值, current value in %), but does not further explain any potential side effects or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, including essential info: report type, data range, source URLs, and return type. The URLs are slightly verbose but provide useful reference. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description adequately explains what it returns (pandas.Series of current values) and the data period. It doesn't detail the exact data structure, but given the simplicity of the tool, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% and no parameter explanations are needed. The description clarifies the return unit and data format, which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a report on Eurozone PPI month-on-month (月率), with a specific data range. It matches the tool name and distinguishes it from other macro indicator tools, though it lacks an explicit verb. The return type and unit are also specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides data range and source URLs but gives no guidance on when to use this tool versus alternatives. There are many sibling macro tools with similar names, and no differentiation or usage context is offered.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds the source URL and return type but does not disclose potential data limitations, update frequency, or network behavior. It provides minimal additional context beyond what annotations already state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the source title, URL, return type, and return format. Every line serves a purpose, and there is no redundant or filler content, making it well-structured for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides the basic essentials: source, URL, and return format. However, it lacks details about the DataFrame's columns, data frequency (e.g., quarterly), units, or time coverage, which could be important for an agent deciding if this tool meets a user's need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, there is nothing for the description to explain. The schema coverage is 100% vacuously, and the baseline for a zero-parameter tool is 4 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a source for German GDP data from the East Money data center, with a specific URL and return type. The name and description together distinguish it from other macro indicators, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many other macro_* tools for different countries or indicators. There are no explicit alternatives, exclusions, or usage context beyond the obvious 'German GDP' implication.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety characteristics. The description adds that it returns a pandas DataFrame of central bank interest rate decisions, which is useful. However, it doesn't disclose any additional behavioral constraints 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title, a source URL, and return information. It is front-loaded with the purpose. The URL may be of limited use to an AI agent, but the overall structure is efficient and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description adequately specifies the output content (central bank interest rate decisions) and format (pandas DataFrame). It provides enough context for basic invocation, though it could mention data granularity or historical range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain input semantics. This is a simple retrieval tool with no inputs, and the schema already reflects this with 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Switzerland's central bank interest rate decisions from East Money data, using a specific title. However, it does not explicitly differentiate from sibling tools like macro_bank_switzerland_interest_rate, 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/5Does 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 similar Swiss macro indicators. It only gives a title and return type, without any context about selection criteria or alternatives.
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 already indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns a pandas.DataFrame and cites a data source URL, but offers no additional details about data behavior, latency, or limitations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and directly states the data source, return type, and purpose in two lines. It is efficiently front-loaded, though the URL might be secondary information. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless data retrieval tool, the description covers the essential points: what data (Swiss GDP quarterly rate), from where (East Money URL), and return type (DataFrame). It lacks an output schema, but the return type hint conveys the shape. This is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 details, but none are needed. Baseline of 4 applies due to absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Swiss GDP quarterly rate from East Money economic data, with a specific return type. It distinguishes from siblings by its explicit Switzerland GDP quarterly scope, though it lacks an explicit action verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or any exclusions. It neither states a preferred context nor mentions related tools, leaving the agent to infer usage solely from the name and URL.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (DataFrame), but does not disclose other behavioral traits such as data update frequency or potential network delays. With annotations present, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title-like line, a source URL, and two docstring lines. Every element is purposeful with no redundancy, appropriate for a zero-parameter data retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides basic context: the source, the subject (UK central bank rate decision), and the return type. However, it lacks details about the DataFrame's columns or the exact nature of the data, and there is no output schema to compensate. Given the simplicity of the tool, this is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so there are no parameter semantics to explain. The description correctly omits parameter details, aligning with the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the subject as UK central bank rate decisions from Eastmoney economic data, and the :rtype: pandas.DataFrame indicates data retrieval. It distinguishes from sibling macro tools by explicitly naming the UK, though it lacks an explicit action verb like 'get' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is implied from the name and title that it relates to UK bank rate, but there is no mention of when to prefer this over sibling tools like macro_bank_english_interest_rate or macro_uk_cpi_yearly.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas DataFrame), but does not disclose details like columns, data period, or potential latency, which are beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title line, a source URL, and a return-type line. Every element is useful and there is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description identifies the data source and return type, but it leaves out structural details of the returned DataFrame (e.g., column names, time range) and any caveats about data coverage. With no output schema, more description would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description appropriately adds nothing about parameters because there are none to explain, matching the baseline for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the UK Halifax house price index yearly rate from East Money, using the Chinese name and URL. It identifies the specific resource, but does not explicitly contrast with the sibling macro_uk_halifax_monthly, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the monthly variant or any other related macro tools, leaving the agent to infer usage solely from the name and description.
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 already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, covering the safety profile. The description adds the source URL (https://data.eastmoney.com/cjsj/foreign_4_9.html) and the return type (pandas.DataFrame), which provides useful context beyond the annotations. No additional behavioral traits like rate limits, pagination, or limitations are mentioned, but none are evident for this zero-parameter data fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title line, a URL, and docstring-style return information. It is front-loaded with the primary purpose. Minor redundancy exists because the first line mirrors the tool name and title annotation, but the text is otherwise free of waffle and each segment earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is reasonably complete. It states the data source, the metric, and the return type. It does not specify the date range, column names, or unit, but these are typically implied by the metric name. Given the low complexity, the description provides sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the input schema is trivially complete. Per the rubric, a baseline of 4 applies when there are no parameters. The description does not need to elaborate on parameter semantics, and it doesn't attempt to invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and metric: '东方财富-经济数据-英国-零售销售年率' (East Money - Economic Data - UK - Retail Sales Annual Rate). It distinguishes this from sibling UK macro tools by naming the exact indicator. However, it lacks an explicit action verb (e.g., 'retrieves' or 'returns'), relying on the docstring-style ':return:' to imply data fetching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_uk_retail_monthly or macro_uk_trade. It neither states use cases nor excludes other tools. The implied usage (need UK retail sales yearly data) is present but not explicitly communicated, so it fails to help the agent make a deliberate selection.
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?
The description adds behavioral context beyond the annotations by stating the data range (19700101-present), the source URL, and the return type (DataFrame). However, it does not disclose whether the full history is returned in a single call or other limitations, but the annotations already declare the tool as safe, read-only, and non-destructive, lowering the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is slightly redundant, repeating '美国核心CPI月率报告' twice and including a docstring-style :return and :rtype. It is compact and each element adds value, but the repetition prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool with rich annotations, the description sufficiently conveys the indicator, data range, and return type. It lacks an output schema but the :rtype hints at a DataFrame. More detail about columns would improve completeness, but the current information is adequate for selecting and using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and an empty input schema (100% coverage), the description need not explain parameter semantics. The baseline for 0 params is 4, and the description adequately clarifies what the tool returns without requiring parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a US Core CPI monthly rate report and specifies its date range (19700101-present). This distinguishes it from similar tools like macro_usa_cpi_monthly by explicitly mentioning 'core' and 'monthly', though it lacks an explicit verb such as 'retrieves' or 'queries'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as macro_usa_cpi_yoy or macro_usa_core_pce_price. There is no mention of exclusions, alternatives, or the intended use case.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context by specifying the data range (19700101-至今), the data source URL, and the return type (pandas.DataFrame). It does not disclose update frequency, exact columns, or any rate limits, but given the strong annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key resource name. It includes a source URL and return type, which are useful. However, it repeats the report name in the ':return:' line and the title duplicates the description's first sentence, adding minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless read-only indicator, the description provides the essential context: what data is returned, the time span, and the source. No output schema exists, but the return type is stated. It lacks explicit periodicity (e.g., monthly vs annual), though '年率' implies yearly rate. Overall, adequate for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (since no properties are defined). The description does not need to explain parameters, and the baseline of 4 is appropriate for a parameterless tool. It correctly returns a DataFrame without requiring any input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides the US Core PCE Price Index Year-over-Year report, with data range from 19700101 to present. The name 'macro_usa_core_pce_price' aligns with this, and it is distinguishable from sibling macro tools like CPI or PPI. However, it lacks an explicit verb like 'get' or 'list', relying on the noun '报告' (report), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description merely describes the report and provides a source URL. It does not mention exclusions, prerequisites, or alternative tools for similar economic indicators, leaving the agent to infer usage from the name alone.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data range (2008-present) and source URL, plus the return type (pandas.DataFrame), but does not disclose details like available columns, data frequency, or potential missing values. This is moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively brief, front-loading the key identifier (source and metric) and including a helpful URL and return type. The docstring-style ':return' and ':rtype' lines are slightly redundant but not harmful. It is efficient and well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), strong annotations, and lack of an output schema, the description provides adequate context: it names the exact economic indicator, data source, date range, and return type. It could be improved by listing typical columns, but that is not critical for a straightforward read-only data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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. Per the baseline for 0 params, this dimension scores 4. The description does not need to add parameter semantics since none exist, and the description confirms no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing US CPI year-over-year data from East Money, with an explicit data range (2008-present). It distinguishes from sibling tools like macro_usa_cpi_monthly by specifying '年率' (annual rate), though it lacks a direct action verb like 'retrieve' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., macro_usa_cpi_monthly or macro_usa_core_cpi_*). It implies usage for US CPI YoY data but does not state exclusions or alternatives, leaving the agent to infer from the name and description alone.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context: the exact data range (20080227-present), a source URL, and the return type (pandas.DataFrame), which go beyond the structured annotations and help set expectations about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but contains redundancy: the ':return:' line repeats the report name from the first line. The URL is useful, but the docstring-style artifacts add unnecessary repetition, making it slightly less polished than a fully concise single-purpose sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool, the description provides the essential facts: what the report is, the data range, the source, and the return type. However, it does not explain the meaning of '月率' (monthly rate) or outline the columns/format of the returned DataFrame, which would be helpful for an agent to interpret the results. It 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuously). The baseline for 0 params is 4, and the description confirms the return type (pandas.DataFrame) which is the only additional semantic needed. No parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the US durable goods orders monthly rate report, with a data range and source URL. However, it lacks an explicit action verb (e.g., 'retrieve' or 'get') and does not differentiate from the many sibling macro_usa_* tools beyond the title itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention any exclusions, prerequisites, or related tools, leaving the agent to infer usage solely from the name and generic description.
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 already declare readOnlyHint=true and idempotentHint=true, so the description does not need to state safety. It adds the data range, source URL, and return type (pandas.DataFrame), which are useful. However, it does not disclose details such as the data's update frequency, seasonal adjustment, or that the tool returns the entire historical series without filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the report name and data range. It includes a source URL and return type. However, the :return: phrase repeats the main title, which is slightly redundant and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only data report, the description is mostly complete: it gives the dataset, time span, source, and return type. The lack of an output schema is mitigated by the explained return type. It could be improved by stating the metric's frequency or units, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100% of the (empty) parameter space, earning a baseline of 4. The description adds no parameter-specific information, but none is needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource: '美国新屋销售总数年化报告' (US new home sales total annualized report) and specifies the data range (19700101-present). This distinguishes it from sibling tools like macro_usa_exist_home_sales and macro_usa_pending_home_sales, though it lacks an explicit action verb like 'fetch' or 'download'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related macro indicators. It does not mention alternatives, prerequisites, or exclusion scenarios. An AI agent would have to infer usage from the tool name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the date range and return type (pandas.DataFrame), which is useful but does not disclose other behavioral traits like columns, data frequency, or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by a source URL and return type. It is a single coherent block though not elegantly structured; the URL is arguably extraneous, but it does not waste many words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description provides adequate context: it identifies the report, the date range, and the return format. Annotations cover safety, so the agent knows it is a safe read operation. It does not enumerate specific columns, but that is acceptable for a straightforward data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage is 100% vacuously). Per the baseline for 0 parameters, a score of 4 is appropriate. The description does not need to explain parameter semantics because there are none, and it does not add confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the US trade balance report ('美国贸易帐报告') with a date range from 19700101 to present. This distinguishes it from sibling tools like macro_uk_trade or macro_china_trade_balance by specifying the USA, though it lacks an explicit action verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 comparisons to sibling macro trade tools. It is not misleading, but there is zero usage direction.
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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that it requires a cookie and returns a DataFrame, but does not mention rate limits, auth requirements beyond cookie, or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a clear title, URL, param docstring, and return type in roughly four lines. It is front-loaded with the purpose, though some redundancy exists between the title and description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by stating return is a DataFrame. It lacks guidance on behavior like what happens when no date is provided (default set in schema) or whether authentication (cookie) is mandatory. The presence of a URL and sibling context helps, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% in the description, but the schema itself defines both parameters. The description does not add meaningful detail about how 'date' should be formatted (though it does show YYYYMMDD) or what 'cookie' is specifically for. However, the docstring includes format hints and return type, providing a baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves Baidu stock trading suspension/resumption data ('百度股市通-交易提醒-停复牌') and returns a DataFrame, with a URL. It identifies the specific data source and type, distinguishing it from sibling tools like news_trade_notify_dividend_baidu.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description reveals this is for Baidu calendar trade notifications on suspensions/resumptions, but does not explicitly state when to prefer it over alternatives or provide exclusions. Usage context is implied by the name and title rather than explicitly stated.
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 already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds useful context: the return type is a pandas.DataFrame containing daily-frequency data, and the symbol includes call/put identifiers. However, it does not disclose any quirks like missing values, date range behavior, or rate limits. Given the annotations cover the main behavioral traits, the extra context is moderate but not rich, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a clear summary line followed by parameter and return fields. It is concise—only the essential details are included, and each line adds value. The format is familiar for akshare-style tools, making it easy to scan. Not perfectly minimal, but appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, idempotent, no output schema), the description is almost complete: it names the source, exchange, underlying index, frequency, parameter semantics, and return type. It lacks an explicit usage note about when to use this vs. alternatives, which is why it doesn't reach a 5, but for this straightforward data-fetch operation, the coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries the full burden for parameter semantics. It explains that 'symbol' is a specific contract code including call/put identifiers and directs users to the spot function to obtain valid codes. This goes well beyond the bare schema (type string, default 'mo2208P6200') and provides actionable guidance for selecting the parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool fetches daily-frequency market data for specified CSI 1000 index option contracts from CFFEX via Sina Finance ('新浪财经-中金所-中证 1000 指数-指定合约-日频行情'). It identifies the resource (CSI 1000 options) and the action (fetching daily quotes), and is distinguishable from sibling tools like option_cffex_zz1000_list_sina and option_cffex_zz1000_spot_sina by its 'daily' and 'specified contract' scope. It does not explicitly name alternatives, but 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite hint—that the contract symbol can be obtained from option_cffex_zz1000_spot_sina via the 'call-标识'—but it does not explain when to prefer this tool over alternatives (e.g., use for historical daily data vs. real-time spot). There is no explicit when-to-use guidance or contrast with sibling daily functions for other indices or the list/spot variants, leaving the agent to infer usage context.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the data frequency (daily) and type (volume/price) plus a source URL, but does not disclose non-obvious behavioral traits such as pagination, date range limits, or return column details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter documentation, and return info. It is front-loaded with the key purpose, contains no redundant sentences, and every line serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read-only tool, the description covers data source, parameters, and return type. However, it does not explicitly state this is option data (relying on the tool name), and it lacks detail on returned columns or date format, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by documenting trade_date as '交易日' and symbol as a choice of {'工业硅', '碳酸锂'}. It also states the return type. The date format is not explicitly described but is implied by the default '20230724', and symbol choices are enumerated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '广州期货交易所-日频率-量价数据' (Guangzhou Futures Exchange daily volume/price data) and returns a pandas DataFrame, indicating it retrieves historical market data. It distinguishes from siblings like option_vol_gfex (volatility) and option_hist_czce (other exchange) by specifying the exchange and data type, though it uses a noun phrase rather than an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit when-to-use or alternative guidance. It does not mention that for other exchanges one should use option_hist_czce/dce/shfe, nor when to prefer this over option_vol_gfex. The usage context is only implied by the exchange and data frequency.
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 already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds the return format (a tuple of expiration time and remaining time) and specific accepted parameter values, which is useful but does not go beyond what a simple read-only utility would imply. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, following a clear docstring format with title, params, return, and rtype sections. Every line contributes necessary information. It is not overly verbose, though the opening sentence could be more action-oriented (e.g., 'Returns the remaining...') rather than a noun phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description covers the purpose, all three parameters, and the return type. It does not specify the unit of 'remaining time' (days vs. seconds) or mention the data source (SSE/Sina), but given the low complexity and supportive annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by providing docstring-style explanations for each parameter: trade_date with example values, symbol limited to '50ETF or 300ETF', and exchange noted as null. It also specifies the return tuple. The examples for trade_date contain a likely typo ('20203' instead of '202003') and the exchange value 'null' is ambiguous, but overall the description adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides the remaining expiration time for a specified expiration month and underlying (50ETF or 300ETF). This distinguishes it from sibling tools like option_sse_greeks_sina (which calculates Greeks) and option_sse_daily_sina (daily data). However, the description is a noun phrase rather than a specific verb+resource, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternative option tools. The description only explains parameter meanings (trade_date, symbol, exchange) and does not mention any exclusions or alternative tools. Since the sibling list contains many option-related functions, this lack of differentiation makes it hard for an agent to know when this is the right choice.
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 already declare the operation as read-only, idempotent, and non-destructive. The description adds that it returns a pandas DataFrame and specifies the data source (East Money), but does not disclose additional behavioral details such as data frequency, date range limitations, or network requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a title, a source URL, and a docstring-style parameter/return section. It is structured and avoids unnecessary filler, though the URL and title repeat each other slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 provides a basic understanding of what it returns (a DataFrame of historical quotes). However, it lacks details about the specific columns, data period, and any limitations, which would be helpful for an agent to interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by explaining that the 'symbol' parameter is a REITs code and provides an example URL with 'sh508097'. However, it does not clarify whether the code should include an exchange prefix, and the default is a bare number, leaving some ambiguity about the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing historical quotes for Shanghai and Shenzhen REITs from East Money, including an example URL. It distinguishes from sibling tools like reits_realtime_em and reits_hist_min_em by focusing on '历史行情' (historical quotes), though it does not state an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the name and description indicate this is for REIT historical data, and the presence of siblings for minute and realtime data suggests when to use it. However, there is no explicit guidance on when to choose this tool over alternatives or any exclusion criteria, so it stops at implied usage.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and a source URL, but does not disclose other behavioral traits such as rate limits or data update frequency. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a short descriptive line, a source URL, and a return-type docstring. It is front-loaded and to the point. The slight redundancy with the title annotation prevents a 5, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool, the description is sufficiently complete. It specifies the data source (URL), the resource (Shanghai Gold benchmark price historical data), and the return format (pandas.DataFrame). The annotations cover safety. No output schema exists, but the return type is disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline for this dimension is 4. The description does not need to explain parameter semantics, and the empty schema confirms that no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Shanghai Gold Exchange benchmark price historical data. It is distinct from the sibling tool spot_silver_benchmark_sge, which covers silver, and the specific wording '上海金基准价-历史数据' makes the purpose explicit. However, it lacks a verb such as 'get' or 'retrieve', instead using a noun phrase, so it is not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 spot_hist_sge or spot_quotations_sge. There is no mention of prerequisites, exclusions, or alternative tools. This is a case of simply no guidance 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the data source URL and return type (pandas DataFrame), but does not disclose additional behavioral details like update frequency or data limitations. With annotations present, this is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes only essential information: the tool's scope, source URL, return value, and return type. The `:return:` and `:rtype:` lines are standard docstring elements and add structure without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with rich annotations, the description is adequately complete. It identifies the data source, the nature of the data (real-time provincial average price ranking), and the return format. While it does not enumerate DataFrame columns, this is not critical given the tool's simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty schema). Per guidelines, the baseline for 0 params is 4. The description correctly indicates no parameters are needed, and no further parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a real-time ranking of average hog prices by province from Soozhu, with a specific source URL and return type. It distinguishes itself from sibling hog tools by focusing on province-level average price rankings, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative hog-data tools such as spot_hog_crossbred_soozhu or index_hog_spot_price. The description is purely descriptive and does not mention use cases 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the data source URL and the return type (pandas.DataFrame), which is useful. However, it does not describe any additional behavioral aspects such as data granularity, time range, or potential delays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring structure with title, URL, param, and return sections. The phrase '破净股统计历史走势' appears twice (as the heading and the return description), which is mildly redundant, but the document is otherwise free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description supplies the necessary invocation details: parameter choices, return type, and source URL. The rich annotations cover safety, so the overall context is sufficient for an agent to call the tool correctly, though it lacks guidance on when to prefer this tool over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' as a string with a default, but the description enriches this by enumerating valid choices: 全部A股, 沪深300, 上证50, 中证500. This directly compensates for the 0% schema description coverage, providing essential information for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: historical statistics of stocks trading below net asset value. The phrase '破净股统计历史走势' is a noun phrase rather than an explicit verb, but the meaning is unambiguous and the URL supports it. It does not explicitly differentiate from sibling tools like stock_a_all_pb, but the scope is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It does not state prerequisites, typical use cases, or scenarios where another tool would be more appropriate. Given the large list of sibling tools, this omission is a notable gap.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and the source URL, which are useful details beyond the annotations. However, it doesn't disclose behaviors like data refresh frequency, scope of statistics, or potential delayed updates, which for a simple read-only tool is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and consists of a titled source, a URL, and a return type annotation. Each element is relevant and there is no redundant fluff. It could be slightly improved by adding a one-sentence summary of the data content, but the current structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only data retrieval tool with no output schema, the description provides the essential context: what data (stock account statistics), from where (East Money data center), and in what format (pandas.DataFrame). It doesn't enumerate columns or granularity, but these are likely inferable from the tool name and source page. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially complete. The schema is empty and schema coverage is effectively 100%. The description reinforces the return type and data source, which is all that's needed for a parameterless tool. Baseline for 0 params is 4, and no further parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (东方财富网-数据中心-特色数据) and the specific dataset (股票账户统计, stock account statistics). The return type and source URL are provided, making it clear the tool fetches this data. However, the verb is implicit rather than an explicit 'get'/'fetch', and there is no direct differentiation from sibling tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the many alternative data-fetching tools in the sibling list. There is no mention of suitable scenarios, exclusions, or alternative tools for similar data. The only contextual clue is the data source and type, which implies a specialized retrieval use case.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds the specific data source URL and confirms it returns a pandas DataFrame. It doesn't add details about network requirements, rate limits, or data freshness beyond the URL, but with annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise: title, URL, param list, and return type. It's structured as a docstring, which is efficient. It includes necessary info without excessive fluff. Could be slightly more organized but overall earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description provides the URL and return type, which is helpful. However, it doesn't mention what the DataFrame contains beyond 'A股股息率' (e.g., columns, time series vs point-in-time), and doesn't state any limitations or examples. Given the simplicity, it's adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but there is only one parameter with a default value. The description does list the enumerated choices in the :param symbol: line, which adds value beyond the schema (which only shows default). However, it doesn't explain the meaning of each choice in depth, but the choices are self-explanatory (e.g., 上证A股, 深证A股). With one simple param and defaults, baseline 3 is reasonable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching A-share dividend yield data (股息率) from 乐咕乐股 (legulegu.com), with a specific URL. It includes a parameter choice for the market segment. However, it doesn't explicitly differentiate from sibling tools like stock_hk_gxl_lg or stock_a_all_pb, though the name and description are quite specific to A-share dividend yield.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving A-share dividend yield for a chosen market segment via the symbol parameter. It does not state when to use this instead of other related tools like stock_hk_gxl_lg (HK dividend yield) or stock_a_all_pb (A-share PB). No explicit alternatives or exclusions are given, but the context is clear enough.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds minimal behavioral context beyond stating the return type (pandas.DataFrame) and the nature of the data. It does not disclose details like pagination, potential errors, or the meaning of the example URL, but it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a hierarchical title, an example URL, parameter documentation, and return type. It is well-structured and front-loaded with the most identifying information. The example URL is slightly redundant but adds reference context without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return structure, but it only says '具体指标的数据' (data of specific indicators), which is vague. The indicator choices hint at the content (e.g., latest tracked constituents, historical index), but no column names or data shape are provided. For a 2-parameter tool returning pandas.DataFrame, this is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for parameters, but the docstring compensates: analyst_id is explained as the analyst ID obtained from ak.stock_analyst_rank_em(), and indicator lists its allowed choices: {'最新跟踪成分股', '历史跟踪成分股', '历史指数'}. This gives clear meaning beyond the raw schema, although it does not clarify the exact output columns for each choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's hierarchical title '东方财富分析师指数2020最新排行-分析师详情' clearly identifies the resource as analyst details within the Eastmoney analyst index. The :return: line states it provides '具体指标的数据' (data of specific indicators), implying retrieval. It is distinguishable from the sibling stock_analyst_rank_em, which focuses on the ranking list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The docstring mentions that analyst_id should be '从 ak.stock_analyst_rank_em() 获取', indicating a dependency on a sibling tool for obtaining valid IDs. However, it does not explicitly state when to use this tool versus alternatives or any exclusions. The usage context is implied through the name and ID source guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type (pandas.DataFrame), which is useful, but it does not disclose any additional behavioral traits such as pagination, network dependencies, or data freshness, which are relevant for this type of tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, consisting of just three lines: title line, URL, and return description. It is concise and front-loaded with the resource name. The inclusion of the URL and return type is efficient, but the lack of a verb sentence makes it slightly fragmented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately specifies the output (all industry sector names and links) and the data structure (pandas.DataFrame). It is sufficient for an agent to know what to expect, though it could mention the scope of industries or time-freshness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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's mention of '所有行业板块的名称和链接' clarifies what the returned data contains, which is helpful even though there is no input schema to elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns all industry sector names and links from 同花顺 (THS), with an explicit URL. The verb is implicit (return/list) but the output is unambiguous. It distinguishes itself by the THS source and the 'industry' category, but does not explicitly differentiate from sibling tools like stock_board_industry_name_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as East Money (EM) or THS concept boards. The description implies it is for industry sector listings but fails to provide context for selection among the many board-related sibling 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds that it returns a pandas DataFrame and returns an empty DataFrame if the source has no records. This adds some behavioral context beyond annotations, but it does not describe the DataFrame's columns or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, URL, parameter documentation, and return type, all in a clear structure. Every line adds necessary information without excess verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only data retrieval with no output schema, and the description explains the return type and empty-case behavior. However, it lacks detail on the expected date format and the specific fields/columns in the returned DataFrame, which limits an agent's ability to use the data without further exploration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), but the description compensates by listing the allowed values for symbol ({'全部', '深市主板', '沪市', '创业板', '科创板'}) and the meaning of start_date and end_date as '开始统计时间' and '结束统计时间'. However, it does not specify the exact date format expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: retrieving corporate lawsuit data from the cninfo Data Center, as shown by the title '巨潮资讯-数据中心-专题统计-公司治理-公司诉讼' and the source URL. The resource is specific and distinct from sibling tools like stock_cg_equity_mortgage_cninfo, though it doesn't explicitly state a verb like 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other lawsuit-related or cninfo tools. The description only states what the tool does and its parameters, with no mention of alternatives or exclusions.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds a meaningful behavioral caveat: for certain stocks at certain times, only the top 5 circulating shareholders are returned (example 000002). It also includes a source URL, which helps set expectations about data origin. This goes beyond the structured annotations, though it doesn't disclose other traits like data freshness or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but not ideally structured. It begins with a label-like phrase rather than a clear functional sentence, and includes a P.S., URL, and docstring with some redundancy (the title '新浪财经-股东股本-流通股东' appears both at the start and in the return). It is not verbose, but the information could be better organized with the purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description provides the return type (pandas.DataFrame) and a source URL, but it does not describe the columns, content, or behavior beyond the top-5 caveat. The P.S. about the top-5 limitation is useful but underexplained. Overall, it is adequate for a simple tool but leaves gaps about the returned data's structure and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines `symbol` as a string with default '600000' and no description. The description compensates by stating `:param symbol: 股票代码` (stock code) and providing an example URL with `stockid=600000`, which clarifies the parameter's meaning. This is minimal but essential, and it partially offsets the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '新浪财经-股东股本-流通股东' (Sina Finance Shareholders Equity - Circulating Shareholders) and includes a source URL and return type, making it clear that it retrieves circulating shareholder data for a stock symbol. However, it lacks an explicit verb like 'fetch' or 'get', and does not differentiate it from sibling tools such as stock_main_stock_holder or stock_fund_stock_holder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only additional note is a limitation ('P.S. 特定股票特定时间只有前 5 个'), but it does not mention any alternative tools or conditions for choosing this one. Sibling tools are not referenced.
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?
The annotations already declare read-only, idempotent, and non-destructive behavior, so the description's job is lighter. It adds the return type (pandas.DataFrame) and the source URL, which are useful context beyond annotations. However, it does not mention any network dependency or scraping behavior, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the data domain, followed by the source URL and return type. All lines contribute meaningful information, though the URL on a separate line and the docstring-style annotations add minor clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool, the description covers the essential aspects: what data (IPO subscription yield), where from (Eastmoney URL), and what is returned (pandas.DataFrame). It lacks detailed column descriptions, but given the simplicity and annotations, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies because there are no parameter fields to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as Eastmoney's new stock subscription yield data (打新收益率) and includes a specific URL, which distinguishes it from other IPO-related tools like stock_ipo_benefit_ths. Although it lacks an explicit verb like 'retrieve', the intent is clear from the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative IPO data sources such as stock_ipo_declare_em or stock_ipo_benefit_ths. The tool is implicitly for fetching this specific dataset, but there is no explicit when/when-not guidance.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and side effects. The description adds the source URL and return type (pandas.DataFrame) but does not disclose behavior like data update frequency, whether the data is historical, or potential network dependencies. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, containing only the display name, source URL, and return type in a structured docstring format. Every element serves a purpose and there is no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides the essential information (name, source, return type) but lacks context about the nature of the data, such as whether it is a time series, what columns it contains, or the period covered. Given the large number of sibling tools, a bit more context would help an agent decide if this matches the user's request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to explain. Per the guidelines, a 0-parameter tool gets a baseline of 4, and the description correctly does not add irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (Legulegu) and the specific metric (equity-bond spread, 股债利差), and states the return type as a DataFrame. This distinguishes it from sibling tools that cover other indicators like PE/PB. However, it lacks an explicit verb like 'retrieve' or 'fetch', relying on context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not describe scenarios, exclusions, or how it differs from related Legulegu tools such as stock_market_pe_lg or stock_index_pb_lg. The agent is left without clear selection criteria.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the source URL, return type, and indicator choices, but does not discuss data freshness, rate limits, or potential edge cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, source URL, parameter documentation, and return type. It is well-structured and free of fluff, though it could be improved by front-loading a single clear sentence of what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter, read-only tool with no output schema, the description provides the source URL, parameter choices, and return type. This is adequate, though it lacks usage examples or caveats that could help in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description provides definitions for both parameters, including the valid choices for 'indicator'. This significantly adds meaning beyond the bare schema, though the symbol explanation is generic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a THS financial indicator (income statement) retrieval tool, identifying the data source URL and the return type as a pandas DataFrame. However, it does not differentiate from the sibling tool stock_financial_benefit_ths, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 among the many financial tools in the sibling list. It only describes what the tool returns, without context on scenarios 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety traits. The description adds minimal behavioral context: the indicator parameter controls report-period vs. annual granularity, and the return type is a DataFrame. It does not disclose rate limits, potential delays, or result-volume characteristics beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but somewhat cluttered: it includes two long source URLs that provide little actionable guidance to an LLM, and it repeats the title in the return field. The docstring style is acceptable but not optimized for tool selection, where a clear purpose and usage summary would be more effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters and no output schema. The description covers the source, parameter semantics, and return type, but does not describe the data content (columns, units, or time coverage) of the balance sheet DataFrame, which would be critical for an agent to interpret the results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description directly compensates by defining 'symbol' as a stock code (股票代码) with type 'str', and 'indicator' as a choice of {'按报告期', '按年度'} (by reporting period, by annual). This provides the most essential semantic meaning for both parameters, though it does not explain the exact format for symbol (e.g., leading zeros, exchange prefixes).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '同花顺-财务指标-资产负债表' (THS Financial Indicators - Balance Sheet), which clearly identifies the tool as a balance sheet data fetcher from Tonghuashun. It also lists the return type as a pandas DataFrame. However, it lacks an explicit verb like 'fetches' or 'retrieves', and the differentiation from sibling tools is implicit via the title rather than a stated comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the title and source URLs, but there is no explicit guidance on when to use this tool versus the many sibling financial-data tools (e.g., stock_financial_abstract_ths, stock_zcfz_em). It also does not mention any exclusions or prerequisites, such as only supporting A-share stocks or requiring a valid symbol.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the return type (pandas.DataFrame) and source URL, providing some context beyond the schema. However, it does not disclose any further behavioral traits such as data coverage, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title line, a URL, and a return type declaration. Every line carries information, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple data retrieval with no parameters and no output schema. The description tells the agent the data source and return type, but it lacks details on the structure of the DataFrame or what specific fields are included, which could be important for selecting this tool. However, given the simplicity, it is minimally acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%, so the description need not explain parameters. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 质押机构分布统计-银行 (pledge institution distribution statistics - banks) from Eastmoney, and by specifying '银行' it differentiates from the sibling company version. However, it lacks an explicit verb like 'retrieves' or 'lists', making it more of a title than a functional 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/5Does 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 provides a URL and return type, with no mention of use cases, exclusions, or alternative 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is light. It adds that the return type is a pandas.DataFrame and the data source URL, which is useful. However, it does not describe columns, data freshness, or any potential exceptions, leaving some behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing a title, source URL, and return type in a structured docstring format. It is only a few lines and has no filler, but the format is a mix of Chinese and code-like syntax rather than a polished natural-language description, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description gives the essential context: what data it returns (港股通成份股), from which source (East Money URL), and as what type (pandas.DataFrame). Without an output schema, it would benefit from listing typical columns, but for a simple constituent list, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the input schema is empty. Per the rubric, a baseline of 4 applies when there are no params, and the description accurately indicates the return type (DataFrame) and content, so no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning 港股通成份股 (Stock Connect constituent stocks) from East Money's market center, and the URL confirms the specific data source. It is distinct from siblings like stock_hk_spot_em by focusing on constituent list rather than quotes. However, it lacks an explicit verb like 'get' or 'fetch', relying instead on a noun phrase and docstring-style :return:.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions, prerequisites, or relation to sibling tools such as stock_hk_spot_em or stock_hk_main_board_spot_em. Usage is only implied by the tool name and topic.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the specific return content (HSI dividend yield), the return type (pandas.DataFrame), and the source URL, which is useful context but does not go into topics like data frequency or update schedule.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes only the essential return info and source URL. However, the first line duplicates the title from annotations, which adds slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool with good annotations, the description adequately explains what is returned and in what format. It doesn't describe the DataFrame's columns, but for this simple case that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers this aspect. Per the baseline for 0 params, this is a 4; the description correctly avoids parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns the Hang Seng Index dividend yield (恒生指数股息率) from Legulegu, with a source URL and a pandas.DataFrame return type. It clearly identifies the resource and is distinct from other HK stock tools, though the retrieval verb is implied rather than 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It simply states the data source and return value without mention of use cases, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that it's a history/daily-quote fetch, but doesn't disclose things like potential rate limits, data source quirks, or how the default dates work (e.g., default start 19700101, end 22220101 might fetch a huge range). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly compact and structured with param/type/return in docstring format. It's front-loaded with the source and URL. Some redundancy exists (e.g., repeating '每日行情' multiple times), but it's mostly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description mentions return is 'pandas.DataFrame' but doesn't detail columns. The tool has 5 parameters, all optional with defaults, and the description explains most but not date formats or symbol format details. Given the complexity of a historical data tool and no output schema, the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains period choices ('daily', 'weekly', 'monthly'), adjust choices ('qfq', 'hfq', ''), and mentions symbol as a string with an example URL. However, it doesn't explain date formats (start_date/end_date) beyond '开始日期' and '结束日期', and the example symbol in URL (08367) differs from schema default (00593). The description adds some value but leaves gaps in date syntax and symbol format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly says it fetches Hong Kong stock daily market data from East Money ('东方财富网-行情-港股-每日行情'), with a URL example. It uses specific verbs like '每日行情' (daily quotes) and indicates resource (HK stocks) and data type (history). However, it doesn't explicitly distinguish itself from sibling tools like stock_hk_hist_min_em or stock_hk_spot_em, though the 'hist' in the name and '每日行情' imply historical daily data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it's for retrieving HK stock daily/weekly/monthly historical data. It provides an example URL and parameter choices (period, adjust). However, it doesn't explicitly state when to use this tool vs alternatives like stock_hk_hist_min_em or stock_hk_spot_em, and doesn't mention exclusions or prerequisites.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is known. The description adds the return type (pandas.DataFrame) but does not mention data currency, update frequency, or any other behavioral nuance. This is adequate but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear title, a source URL, and a return type. There is no redundant or filler content, and the structure is easy to parse. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter spot data tool, the description is minimally sufficient but leaves gaps. It does not specify the DataFrame columns (e.g., stock code, name, latest price, change) or confirm the full scope of 'main board' coverage. Since there is no output schema, additional detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% coverage (it is an empty object). The description adds no parameter-specific semantics, but with no parameters to clarify, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing real-time quotes for Hong Kong Main Board stocks from Eastmoney, which is a specific verb+resource combination. It does not explicitly contrast with sibling tools, but the 'main board' scope in the name and title inherently differentiates it from tools like stock_hk_index_spot_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other Hong Kong stock spot tools. The description lacks any contextual hints, prerequisites, or alternative suggestions, leaving the agent to infer usage from the name alone.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety expectations. The description adds that the tool returns 实时行情数据 (real-time market data) as a pandas.DataFrame, which is helpful, but it does not disclose additional behavioral traits such as rate limits, data freshness, or network dependencies. It adds some value beyond annotations but remains limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose in the first line followed by a source URL and return type. It is efficient and front-loaded, though the Vim-style docstring formatting (:return:, :rtype:) is slightly unconventional for a tool description but not confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description adequately covers what data is returned (real-time quotes for all HK stocks), the source (Sina Finance), and the return type (pandas.DataFrame). There is no output schema, so the description carries the burden of explaining the return value, which it does sufficiently. It could mention detailed columns or limitations, but for a simple list endpoint, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the baseline score is 4. The description does not need to explain any input semantics since none exist, and it correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns real-time market data for all Hong Kong stocks from Sina Finance, including a source URL. It is specific about scope and resource, but does not explicitly differentiate from sibling tools like stock_hk_spot_em or stock_hk_index_spot_em, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states what data it returns without any contextual hints or exclusions, leaving the agent to infer usage independently.
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 already declare the tool as read-only, non-destructive, idempotent, and open-world. The description adds only the return type (DataFrame) and source URL, with no additional behavioral details like pagination or data scope. This is adequate but not rich, earning a baseline score given the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and relevant, containing only the source, URL, return value, and return type. It could be more structured with a clear sentence, but it avoids unnecessary verbosity and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple no-parameter read-only nature and the presence of annotations, the description sufficiently conveys the tool's purpose and return type. However, it could be more explicit about the exact scope (e.g., 'all Hong Kong stocks') and any limitations, making it just short of a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 offers no parameter information, but none is needed; the schema is empty and the description does not need to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing real-time Hong Kong stock quotes from Eastmoney, with a source URL. It distinguishes from siblings like stock_hk_spot and stock_hk_main_board_spot_em by naming the source and the general HK stock scope, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or exclusions, leaving the agent to infer its applicability from the name and description alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds that it returns a pandas.DataFrame and includes a source URL, but it does not disclose any further behavioral traits such as data freshness, rate limits, or authentication needs. This is adequate but not rich, given the safety annotations already cover the main concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with a title, URL, parameter definitions, return type, and return description. It is dense but not bloated, with no wasted words. The format is conventional and easy to parse, and the sample URL is useful. It could be slightly more concise by combining the title and URL, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional parameters, no output schema, safe read annotations), the description is reasonably complete. It documents all parameter choices, identifies the data source, and specifies the return type. It does not explain the exact structure of the returned DataFrame or handle edge cases, but for a straightforward valuation data fetch, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the full burden for parameter documentation. It provides type and valid choices for indicator (总市值, 市盈率(TTM), etc.) and period (近一年, 近三年, 全部), and includes defaults for symbol and period. The sample symbol '06969' clarifies the expected HK stock code format. This goes well beyond the bare schema, though it does not explain the meaning of each indicator.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as obtaining valuation data for Hong Kong stocks from Baidu's stock platform, with a sample URL (https://gushitong.baidu.com/stock/hk-06969). The title '百度股市通-港股-财务报表-估值数据' and the name make the purpose unambiguous, and the Baidu source distinguishes it from Eastmoney-based sibling tools. However, there is no explicit verb like 'retrieve' or 'query', so it falls short of a fully specific verb+resource phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description simply states the data source and parameters without mentioning any use cases, prerequisites, or exclusions. It neither names alternative tools nor gives context for when this Baidu-sourced data would be preferred over other HK stock valuation 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds the data source URL and the pandas.DataFrame return type, but says nothing about failure modes, data freshness, pagination, or other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with about five lines covering source, URL, parameters, and return type, with no filler. The structure is slightly marred by the misaligned :param/:type docstring entries and the raw encoded URL, but it remains front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since no output schema exists, the description should compensate by detailing return values; it only names the return ('人员增减持股变动明细') and type (pandas.DataFrame) without listing expected columns. It also does not clarify how name and symbol combine, though both have defaults, leaving agents uncertain about result fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by providing Chinese semantics: symbol=股票代码 (stock code) and name=高管名称 (executive name), adding meaning beyond the bare string schema. However, the :type docstring lines are swapped with the :param lines, and no format constraints are given beyond the defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: East Money executive-holdings personnel increase/decrease shareholding change details, reinforced by the source URL. However, it lacks an explicit action verb and does not distinguish itself from the closely named sibling stock_hold_management_detail_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the parameter docs (query by stock code and executive name) and the breadcrumb path under 数据中心-特色数据-高管持股. No explicit when-to-use, when-not-to-use, or alternative tool guidance is provided, especially versus sibling tools like stock_hold_management_detail_em.
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 already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal extra behavioral context, essentially stating that it returns a pandas DataFrame. It does not disclose additional specifics like whether the data is real-time, what the freshness might be, or any quirks of the source. Given the strong annotations, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. It begins with the title, includes a source URL, and then provides concise docstring-style explanations for the parameter and return type. Every element earns its place, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool, the basic operation is covered. However, it lacks practical selection guidance among the many hot-rank sibling tools, does not mention what columns the returned DataFrame contains, and could be more explicit about whether the ranking is for a single stock or a list. These gaps leave an agent with some uncertainty about the tool's full capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'symbol' with no description. The description compensates by explaining it is a '带市场表示的证券代码' (stock code with market prefix), which clarifies the expected format (e.g., SZ000665). This adds meaningful guidance beyond the bare schema, though it could give more detail on valid prefixes and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves the latest stock popularity ranking from East Money (东方财富-个股人气榜-最新排名). It names the resource and the action. However, it does not explicitly differentiate among sibling tools like stock_hot_rank_em or stock_hot_rank_detail_em, leaving some ambiguity about its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention that stock_hot_rank_em might be for full rankings or that stock_hot_rank_detail_em provides details. The description only states the basic functionality without guiding an agent toward or away from this 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing a safe, idempotent read operation. The description adds context by naming the data source and specifying the return type as pandas.DataFrame, but does not cover pagination, rate limits, or other behavioral traits, which is acceptable given the low-risk read profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title line, URL, parameter definitions, and return type, all front-loaded. It is structured and not overly verbose, though the title and return section repeat the same phrase 'specific stock detail'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query with three parameters, the description gives the source, all parameter meanings, defaults, and return type (DataFrame). It could benefit from clarifying date format or listing possible edge cases, but the information provided is sufficient for typical use of this data-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description's docstring explicitly defines each parameter (symbol=stock code, start_date/end_date=time range) and provides an example URL with a concrete symbol (002008). The defaults in the schema also hint at the date format, making parameter usage reasonably clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear hierarchical source label (East Money Data Center → HSGT → HSGT Holdings → Specific Stock Detail) and a URL with an example, making it clear this tool retrieves detailed HSGT holding data for an individual stock. It doesn't use an explicit verb like 'get' or 'list', but the resource and scope are specific enough to distinguish it from other HSGT 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/5Does 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 stock_hsgt_hold_stock_em or stock_hsgt_individual_em. There is no mention of use cases, prerequisites, or exclusions; it only repeats the title and parameter specs.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the essential safety profile. The description adds the explicit return type (pandas.DataFrame) and the source URL, which are useful behavioral details. However, it does not disclose data freshness, column contents, pagination, or potential latency, though for a simple no-parameter snapshot, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, containing a title line, a source URL, and a return type. The :return: line redundantly repeats the title, introducing a minor duplication, but the overall structure is front-loaded and easy to scan. It avoids extraneous prose and includes necessary identity facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter data retrieval tool, the description adequately covers the data subject (Shanghai-HK Stock Connect SH->HK spot), the data source (Eastmoney URL), and the return type (DataFrame). It does not enumerate columns or explicitly state that the data is real-time, but the term 'spot' and the nature of the dataset imply current quotes. Given the lack of parameters and absence of an output schema, this is sufficiently complete for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is already fully specified and the description adds no parameter-level semantics. According to the rubric, zero parameters warrant a baseline of 4. The description does not need to compensate for missing parameter information because there is none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific dataset from Eastmoney's market center: Shanghai-HK Stock Connect (SH->HK) spot stocks, and includes the source URL and return type. This distinguishes it from sibling tools like stock_hk_spot_em or stock_hsgt_hold_stock_em by naming the exact market segment. However, it lacks an explicit verb such as 'get' or 'fetch', relying on the tool name and DataFrame return type to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool instead of alternatives such as stock_hk_spot_em, stock_hsgt_fund_flow_summary_em, or stock_hsgt_hist_em. It also fails to clarify whether the data is real-time, historical, or suitable for specific analytical contexts, leaving the agent to infer from the tool name alone.
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 already declare this as read-only, idempotent, and non-destructive. The description adds the source URL and return type but does not disclose additional behavioral details such as data freshness, pagination, or rate limits. Since the annotations cover the safety profile, a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and directly to the point, containing only the essential elements: the title, source URL, parameter definition, and return type. Every line adds value, and 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one optional parameter, and the description provides the URL and return type. However, the return is described merely as '终止上市公司' without detailing the DataFrame's columns or structure, which would be helpful given there is no output schema. It is sufficient for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the `symbol` parameter (0% coverage), but the description explicitly lists the valid choices: `{"全部", "沪市", "科创板"}`. This compensates for the schema gap, though it doesn't elaborate on the meaning of each choice beyond their obvious translations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '上海证券交易所-终止上市公司' (Shanghai Stock Exchange - terminated listed companies) and provides the exact source URL, making the tool's scope unambiguous. It is distinguished from siblings like `stock_info_sz_delist` by the 'sh' in the name and the explicit Shanghai reference, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, nor does it mention sibling tools such as `stock_info_sz_delist`. Usage is only implied by the parameter choices (`全部`, `沪市`, `科创板`), which suggest filtering by market segment, but there is no stated scenario or exclusion criteria.
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 already declare readOnlyHint, idempotentHint, and destructiveHint as safe, so the description is not burdened with safety disclosure. It adds a source URL and states the return type is a pandas DataFrame, but does not detail rate limits, data freshness, or other behavioral traits. There is a minor inconsistency referring to 'indicator' instead of 'symbol'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring format with URL, parameter, type, and return lines. However, it contains a terminology inconsistency and the sentence structure is somewhat repetitive, making it less polished than ideal. Despite these issues, it remains brief and generally understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only specifies the return type (DataFrame) and the source, but does not describe columns or row scope. For a simple stock list tool where the symbol category determines the content, this is adequate, but it leaves the agent guessing about the exact data structure. The inclusion of a source URL adds some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a single symbol parameter with no description (0% coverage), so the description must compensate. It does so by enumerating the allowed values (A股列表, B股列表, CDR列表, AB股列表) and indicating a default, which is actionable for the agent. The return line's reference to 'indicator' is slightly confusing, but the parameter choices are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Shenzhen Stock Exchange stock list with a source URL and specific symbol categories (A股列表, B股列表, CDR列表, AB股列表). It distinguishes itself from sibling tools like stock_info_sh_name_code by focusing on the Shenzhen exchange, though the action verb is implied rather than explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the exchange and the parameter choices, but it does not explicitly state when to use this tool versus alternatives or any exclusions. There is no mention of scenarios best suited for this tool or comparisons to similar list 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type, but does not disclose data freshness, scope limitations, or other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short lines: a title, a URL, and return type info. Every element is purposeful with no wasted words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema and rich annotations, the description covers the essentials: data source, market scope, and return type. However, it omits details about the columns in the returned DataFrame or any potential limitations, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The baseline score of 4 applies, as the description is not required to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns insider transaction data for Shanghai/Shenzhen stocks from Xueqiu, and specifies the return type as pandas.DataFrame. It identifies the data domain distinctly, though it lacks an explicit action verb like 'retrieve' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, related tools, or any conditions for use, leaving the AI agent without context for selecting this tool over siblings.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the source URL and the fact that it returns a pandas DataFrame, which is useful but does not go into deeper behavioral details such as data freshness, pagination, or response size. Since annotations carry the safety burden, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with the source URL, parameter documentation, and return type, all in a standard format. The list of symbol choices is somewhat long but necessary and does not add excessive verbosity. It is efficient and front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description provides sufficient context: the data source, the valid parameter choices, and the return type (pandas DataFrame). Combined with the default value in the schema, an agent can reasonably invoke the tool. It is not perfect because it lacks examples or explanation of the default behavior, but it is adequate for simple read-only data retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' as a string with a default, but the description enriches it with an explicit list of valid choices: '最新投资评级', '上调评级股票', '下调评级股票', '股票综合评级', '首次评级股票', '目标涨幅排名', '机构关注度', '行业关注度', and '投资评级选股'. This adds significant meaning beyond the bare schema, though it does not explain what each choice returns in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource '新浪财经-机构推荐池-最新投资评级' and includes the source URL, making it clear this tool retrieves latest investment ratings from Sina Finance's institutional recommendation pool. However, it does not explicitly distinguish itself from closely related siblings like stock_institute_recommend_detail or stock_institute_hold, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists the symbol choices and return type, but does not explain use cases, prerequisites, or situations where another tool (e.g., stock_institute_recommend_detail) would be more appropriate. This is a clear gap.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and the data source URL, but doesn't disclose any additional side effects or edge cases. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is compact, containing only the title, source URL, parameter help, and return type. Each element serves a purpose, though the structure is somewhat docstring-style rather than natural language, it remains efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only report fetcher with no output schema, the description covers the key aspects: what it returns, the parameter options, and the source. It doesn't list the columns or content of the report, but given the low complexity and strong annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a `time_period` string with a default but no description. The description compensates by enumerating the valid enum values and their human-readable labels (e.g., CNHOUR12 means 12 hours), which is essential for correct usage. This goes beyond the schema's bare type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as a Weibo sentiment report from the Jin10 data center, with a parameterized time period, and the return statement confirms it returns the report. This distinguishes it from sibling `stock_js_weibo_nlp_time` by being a report rather than NLP time-series data, though it lacks an explicit verb like 'fetch' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only usage context is the time_period parameter dictionary, which implies the caller chooses a period, but no exclusions or comparisons to similar tools such as `stock_js_weibo_nlp_time` 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the source URL and return type (pandas.DataFrame), but does not disclose any further behavioral traits such as rate limits, data freshness, or delimiters. It provides some value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured as a docstring, with a URL, parameter specification, and return type. It avoids excess prose, though the title phrase is repeated in the return description, making it slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no output schema, and a simple read-only operation, the description includes the key elements: data source, parameter choices, and return type. It omits details like default behavior or output columns, but for this complexity level it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string 'symbol' with a default, while the description specifies the valid choices (近一月, 近三月, 近六月, 近一年). This meaningfully compensates for the schema's 0% description coverage, though it does not explain the period semantics explicitly (e.g., '近一月' = last month).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's resource: East Money's data center for Dragon-Tiger List institutional seat tracking (机构席位追踪), with a specific URL. The verb is implicit ('returns' via the return type), and the tool is differentiated from siblings by the 'em' source and the statistic name, though not an explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The usage is only implied by the description itself (e.g., choosing a 'symbol' period), with no mention of exclusions or simply when to prefer this over other LHB tools. This is a clear gap for tool selection among many similar siblings.
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 already declare read-only and idempotent behavior, so the description does not need to repeat that. It adds the return type (pandas.DataFrame) and the official SSE URL, providing some context about data source and format. However, it does not disclose potential rate limits, date restrictions, or payload structure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, with a title, URL, and docstring lines. There is no redundant text, and each element contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple two-parameter data retrieval tool with strong annotations, the description provides sufficient context: source exchange, URL, parameter meanings, and return type. It lacks detailed column information, but the title '融资融券汇总' conveys the content, making the description adequate for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and defaults with no descriptions, but the description includes a docstring that explains both start_date and end_date as transaction start and end dates. This adds meaning beyond the schema, though the date format (YYYYMMDD) is only implied by the defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly identify this as a Shanghai Stock Exchange margin trading summary data retrieval tool, with a source URL and parameter documentation. It distinguishes itself from sibling margin tools by specifying the exchange and summary granularity, though it lacks an explicit verb like 'fetch' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative margin data tools such as stock_margin_szse or stock_margin_detail_sse. The description only documents its own parameters and return type, leaving the agent to infer use cases from the title.
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 already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context by specifying the 100-news limit, data source (Eastmoney), and pandas DataFrame return type, but omits potential error cases or rate limits. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, combining a title, a reference URL, and structured docstring lines for parameter and return type. Every line adds information without fluff, though the URL could be considered optional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool, the description covers the essential aspects: what it returns, the source, and the fixed limit. The lack of an output schema is mitigated by the stated return type, though exact columns of the DataFrame are not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `symbol` is documented as 股票代码 (stock code), and the example URL with keyword=603777 reinforces its meaning. This adds semantic value beyond the schema's bare type and default, making the parameter's purpose clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides the latest 100 individual stock news from Eastmoney, including a sample URL and parameter documentation. It is not a tautology and distinguishes from generic news tools, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions or recommend other tools for different scenarios, leaving the agent to infer usage from the name and description.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the return type (pandas DataFrame), the source URL, and the filtering options for symbol and date, which goes beyond the annotations. It doesn't discuss rate limits or data freshness, but does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured like a docstring with a source URL, parameter definitions, and a return type. It is information-dense without unnecessary fluff, though the URL could arguably be omitted. The format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two simple parameters, no output schema, and strong annotations, the description is nearly sufficient. It states the data source, the filtering capabilities, and the return type. However, it does not mention any pagination or data size limitations, which would be relevant for a broad announcement feed. Overall, it is adequate for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (0% coverage), so the description carries the full burden. It fully enumerates the allowed values for symbol (e.g., 全部, 重大事项, etc.) and describes date as the announcement date with a default format hint via the schema's default value '20220511'. This is strong compensation, though the date format could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Shanghai/Shenzhen/Beijing A-share announcements from the East Money data center, including the source URL and parameter details. It distinguishes itself from the sibling stock_individual_notice_report by specifying the market-wide scope, though it lacks an explicit action verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter documentation but no guidance on when to choose this tool over the many sibling tools, such as stock_individual_notice_report for single-stock notices. No exclusions or alternative recommendations are given, leaving the agent to infer use cases.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat safety. It adds the data source URL and return type (pandas.DataFrame), but does not disclose output shape or scope, which is a minor 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes structured param/return docstrings, but repeats the same phrase '美股目标价 or 港股目标价' twice. The URL adds context but could be trimmed without loss of essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only states the return is a DataFrame of US/HK target prices, but does not explain columns, row scope, or how to filter for a specific stock. The singular optional parameter (symbol=us/hk) suggests market-level results, but this is not clarified, leaving a significant gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents the parameter: ':param symbol: choice of {"us", "hk"}' and type str. This fully compensates for the lack of schema descriptions and clarifies the allowed values, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning US or HK stock target prices (目标价), using '美股目标价 or 港股目标价' and a return type. It distinguishes from sibling spot-price tools like stock_us_spot and stock_hk_spot, but lacks an explicit action verb such as 'get' or 'list', making it slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 specifies the parameter choices (us/hk) and return type, without exclusions, prerequisites, or references to similar tools. The URL is a source link, not usage context.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds the return type (pandas DataFrame) and source URL, but does not disclose additional behavioral aspects like data freshness, network dependencies, or output structure beyond the type. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title-like Chinese label, a URL, and a short return type specification. Each piece of information serves a purpose, and the description is front-loaded with the key identifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description only states the return type and a vague content description ('连续下跌' - consecutive decline). It does not specify what columns or data the DataFrame contains, nor any caveats about the data. This is adequate for a basic tool but leaves gaps about the returned data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, as confirmed by the empty input schema. The description adds nothing about parameters because none exist; the baseline of 4 is appropriate given the vacuous schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly labels the tool as a ranking from 同花顺's data center for consecutively declining stocks, with a source URL and return type. It distinguishes itself from sibling rank tools via the specific label '连续下跌' (consecutive decline), though it lacks an explicit verb like 'fetches' or 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. It is merely a label with a URL and return type; usage is only implied by the name and title, with no mention of exclusions or alternatives.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the return type is pandas.DataFrame and includes the source URL, but does not disclose any additional behavioral traits such as data freshness, column contents, or potential network dependencies beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title line, a source URL, and return type documentation. Every piece of content serves a purpose, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only), the description is mostly sufficient, but the absence of an output schema means the description should more explicitly explain what the returned DataFrame contains (e.g., currency pairs, buy/sell rates, or timestamps). The current description only says '参考汇率' without detailing columns or how these rates are computed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema description coverage is 100% by nature. There is nothing for the description to add about parameter meanings; the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '参考汇率' (reference exchange rate) for the Shanghai-Hong Kong Stock Connect on SSE, with a source URL. It distinguishes from sibling tools like stock_sgt_settlement_exchange_rate_sse and stock_sgt_reference_exchange_rate_szse through the 'reference' and 'sse' qualifiers, though it lacks an explicit action verb such as 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 reference rates differ from settlement rates, nor does it point to SSE versus SZSE variants, so an agent cannot tell which tool fits based on the description alone.
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 already declare the tool read-only, idempotent, and non-destructive, so the description's lack of behavioral disclosure is acceptable. The included source URL adds minor context about the data origin, but no additional behavioral traits (e.g., pagination, rate limits) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title, a source URL, and a return type docstring. Every element earns its place, and the most important information (what is returned) is front-loaded in the title and return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the return type and source URL, and the annotations cover safety characteristics. However, it lacks any detail about the columns or structure of the DataFrame, and does not clarify its relationship to sibling tools (e.g., settlement vs reference, SZSE vs SSE). Given the simple zero-parameter nature, it is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, so there are no parameter semantics to clarify. The baseline score of 4 applies, and the description's lack of parameter information is appropriate because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the settlement exchange rate for SZSE Stock Connect and indicates a pandas DataFrame return type. However, it does not explicitly distinguish itself from sibling tools such as the reference exchange rate or the SSE version, relying on the name to carry that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like settlement vs reference exchange rates or SSE vs SZSE. It is not misleading, but it provides zero contextual direction for tool selection.
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?
The annotations already declare the read-only, idempotent, and non-destructive nature. The description adds the return type (pandas.DataFrame) and a URL to the source data but includes no additional behavioral details such as update frequency or data freshness. This is acceptable but minimal for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the name, but it repeats the same phrase '上海证券交易所-总貌' in the title and the return docstring. The URL is useful and there is no wasted prose, but the repetition is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the essential information: what it returns and from where. It could mention the DataFrame columns or how current the data is, but for a zero-parameter summary endpoint, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object, so the description is not expected to elaborate on parameters. The baseline of 4 applies because there is nothing to add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource: '上海证券交易所-总貌' (Shanghai Stock Exchange Overview) and provides the source URL, distinguishing it from sibling tools like stock_szse_summary. However, it lacks an explicit verb such as 'fetch' or 'get', so it reads as a noun phrase rather than a command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios, prerequisites, or exclusions, leaving an agent without the information needed to choose between this and related SSE/SZSE summary 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that it returns a pandas DataFrame and provides a source URL, but it does not disclose other behavioral traits such as data frequency, sorting, or error handling. This is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a title line, a source URL, and docstring-style parameter/return documentation. No redundant text, and the structure is logical. It earns a 4 rather than 5 because the param format detail is incomplete, but it is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and only one parameter, the description is reasonably complete: it states the purpose, parameter meaning, and return type. However, it lacks explicit usage context (when to choose this over sibling summary tools) and precise date format specification, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'date' parameter (0% coverage). The description compensates by stating it is the 'most recent trading day' and a string type, with a default '202203' hinting at a YYYYMM format. However, the format is ambiguous (month vs. day), and the description does not clarify the exact expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '深证证券交易所-总貌-地区交易排序' (Shenzhen Stock Exchange - Overview - Regional Trading Ranking), which identifies the specific data resource. It also includes the source URL and explicitly returns a pandas DataFrame of regional trading rankings, distinguishing it from sibling tools like stock_szse_summary or stock_szse_sector_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The only hint is the date parameter description ('最近结束交易日'), but there is no mention of exclusions or preferred use cases compared to similar summary 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?
The annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the return type (pandas.DataFrame) and the source URL, which provides some context but doesn't disclose details like potential network requirements or data freshness. This is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with labeled sections for URL, params, and returns. No unnecessary words, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data-fetching tool with one optional parameter and no output schema, the description provides the essential context: data source, input parameter, and return type. The only gap is the lack of usage guidance, but that is already covered in the usage_guidelines dimension. It is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single optional parameter with 0% description coverage. The description compensates by documenting the parameter with an example value ('20240426') and labeling it as a query parameter. However, it does not explicitly specify the expected date format (YYYYMMDD), relying on the example to convey that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as sourcing East Money's data center suspension/resumption information and returns a pandas DataFrame. It clearly specifies the resource and data type, though it lacks an explicit action verb like 'get' or 'query'. The name also hints at the purpose, but the description makes it concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other financial data tools, no prerequisites, and no mention of alternatives. The description simply documents the input and output.
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 already establish the tool as read-only, idempotent, and open-world, so the description does not need to repeat that. It adds useful context: the source URL, valid date format (YYYYMMDD), and the starting date 20100331. However, it does not disclose potential failure modes, network dependency, or response behavior beyond returning a DataFrame, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with a title and URL, then structured as a docstring with param and return sections. It avoids redundancy except the repetition of '现金流量表' in title and return, which is minor. It is easy to scan and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read-only tool with no output schema, the description sufficiently covers the input contract and return type. It identifies the data source, the date constraint, and the output as a pandas DataFrame. It lacks details about the DataFrame's columns and usage context, but given the low complexity and rich annotations, it is adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string type and default with no description, so the description carries full burden for the single parameter. It explains the date format, gives example values (20200331, 20200630), and specifies that valid dates start from 20100331, which is essential for correct invocation. It does not explicitly state that dates must be quarter-end, but the examples strongly imply it, so the semantics are adequately covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as a cash flow statement (现金流量表) from East Money's data center, with a source URL. It clearly states the domain (年报季报/业绩快报) and return type, distinguishing it from other statement tools like stock_zcfz_em (balance sheet) and stock_lrb_em (income statement). However, it lacks an explicit verb like 'get' or 'retrieve' and could be mistaken for other cash-flow tools (e.g., stock_cash_flow_sheet_by_report_em) without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 indicate whether to choose this over stock_cash_flow_sheet_by_report_em or other statement tools, nor does it mention prerequisites or exclusions. It only describes the tool's own behavior.
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 already establish that the tool is read-only, idempotent, and non-destructive. The description adds the return type (pandas.DataFrame) and the date range starting from 20100331, which is useful context. However, it does not disclose any additional behavioral traits such as potential errors, network dependencies, or handling of invalid dates, which would be helpful for a network-fetching 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured docstring with clear sections for title, URL, parameters, return type, and return object type. Every element serves a purpose without redundancy, making it easy for an agent to parse and extract the essential information quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, and the description covers the source, parameter format, and return type. However, it lacks explicit usage rules (e.g., that 'date' is optional, how to handle unavailable dates, or when to choose this over sibling tools). These gaps reduce the overall completeness for an AI agent, though the core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'date' as a string with a default, but the description adds significant detail: it provides valid format examples ('20200331', '20200630', etc.) and states the start date ('从 20100331 开始'). This compensates for the schema's 0% description coverage and gives the agent concrete guidance on constructing valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool fetches a balance sheet from East Money's performance express section, as indicated by the title '东方财富-数据中心-年报季报-业绩快报-资产负债表' and the return type '资产负债表'. It clearly identifies the resource and the data category, but lacks an explicit verb like 'fetch' or 'retrieve' and does not differentiate itself from other balance sheet tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. While it mentions the data source and the date format, it does not explain that this tool is specifically for performance express balance sheets or how it differs from other balance sheet tools like stock_balance_sheet_by_report_em. The implicit use case is inferred from the title and URL, but no exclusions or alternatives are given.
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 already declare the tool read-only and idempotent. The description adds that it returns real-time quotes as a pandas DataFrame, which is useful context beyond the annotations. However, it does not mention other behavioral traits like data freshness, pagination, or specific fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a title line, a source URL, and return type information. Each element serves a purpose without excess verbosity, though it could be slightly more explicit about the data scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool, the description provides essential context: data source (Eastmoney), market scope (沪深京), data type (AB股比价), and return type (pandas DataFrame). No output schema exists, but the return type is stated clearly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters in the schema, so parameter documentation is not needed. The description makes no parameter claims, and the baseline for zero parameters is appropriately 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving AB-share comparison real-time quotes from Eastmoney's market center, specifying the market scope (沪深京) and data type (AB股比价). It includes a source URL, which adds credential. However, it lacks an explicit verb like 'get' or 'fetch', reading more like a title than a functional statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_zh_ah_spot or stock_zh_b_spot. The description only states what it returns, with no context about scenarios 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds the data source (East Money) and return type (pandas.DataFrame), but does not disclose any additional behavioral details such as rate limits, pagination, or how adjust values affect data. It does not contradict annotations, so it scores at a baseline level for a read-only historical 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a URL that is not essential for an AI agent and the structure mixes a Chinese title, URL, and parameter docs in a single block. While the parameter docs are useful and clear, the overall presentation is not as concise or well-structured as it could be, with extraneous URL and redundant title information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, so the description should explain the return format. It only states the return is '每日行情' (daily quotes) of type pandas.DataFrame, without detailing columns or data granularity. This is minimally sufficient but lacks the richness needed to fully understand the output and edge cases, especially given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter documentation. It provides detailed docs for all six parameters, including choices for period and adjust, date semantics for start_date/end_date, and timeout as None or positive float. This fully compensates for the missing schema descriptions and gives an agent everything needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (East Money A-share daily quotes) and includes the URL source. The parameter list for period and adjust indicates it's a historical data retrieval tool. However, it lacks an explicit verb like 'fetch' or 'retrieve', and it does not differentiate itself from siblings like stock_zh_a_daily or stock_zh_a_hist_tx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply lists parameters and return type, with no mention of scenarios, prerequisites, or exclusions. The sibling tools offer similar functions (e.g., stock_zh_a_hist_min_em, stock_zh_a_daily), and this description does not help an agent choose among them.
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 already declare this as a safe, read-only, idempotent operation, so the bar for additional behavioral disclosure is lower. The description adds that it returns a pandas DataFrame and references the Eastmoney gridlist ST board URL, which provides provenance. However, it does not disclose any further behavioral traits such as column contents, data freshness, or that it is a real-time snapshot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title, a URL, and return type annotation. Every sentence earns its place, providing the data source, the exact board type, and the return format. There is no fluff or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with no output schema, the description is adequate but not complete. It states the source and return type but does not describe what the DataFrame contains (e.g., columns like code, name, change percentage) or whether the data is historical or real-time. Given the many sibling stock tools, a bit more detail about the board's content would help an agent invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter semantics, and no parameter information is missing. The empty schema is fully covered by the description's implicit 'no parameters needed' context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Eastmoney's Shanghai/Shenzhen A-share risk warning board (ST stocks), including the specific URL and return type as a pandas DataFrame. It lacks an explicit verb ('get' or 'list'), but the title and name make the function's purpose clear. It is distinguishable from sibling stock tools by the 'st_board' reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it does not mention that this is for ST/risk-warning stocks specifically, nor does it point to stock_zh_a_spot_em for regular A-share spot data. The description is purely informational with 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the description adds useful behavioral context: the Sina Finance source URL, IP-ban risk under heavy scraping, and pandas DataFrame return type. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and front-loads the core purpose plus warning, but the first sentence exactly duplicates the annotation title. The :type lines repeat schema type information, and the URL adds useful source context but also length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only historical data fetch with four parameters, the description covers inputs, defaults, and adjustment semantics. However, without an output schema, it only promises 'specific data' as a DataFrame and does not describe expected columns, date range behavior, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the docstring compensates by documenting all four parameters: date format '20201103', symbol example, and detailed adjust modes (qfq, hfq, factors). Minor inconsistency: the example symbol sh600000 is an A-share code, while the schema default sh900901 is the B-share format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '新浪财经-B 股-个股的历史行情数据', clearly identifying the resource as Sina Finance B-share historical quotes for individual stocks. It lacks an explicit verb like 'fetch/query' but the noun phrase plus tool name makes the purpose clear; the 'daily' distinction from B-share spot/minute siblings is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_zh_b_spot or stock_zh_b_minute. The only usage-related note is '大量抓取容易封 IP', a rate-limit warning, which is not a selection guideline.
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 already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the source URL and return type (pandas.DataFrame), which is useful but does not disclose any additional behavioral traits like pagination or data coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the exact data source, and includes only necessary details: source, URL, and return type. Every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool with strong annotations, the description is mostly complete. It identifies the source and return type, though it does not mention what columns or rows are included in the DataFrame, leaving minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 reinforces the return type (pandas.DataFrame) and the specific data content, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as AMAC's information disclosure for securities company direct investment funds, and states it returns a pandas.DataFrame. However, it lacks an explicit verb like 'retrieve' or 'list', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling AMAC tools (e.g., amac_fund_info, amac_fund_sub_info). The description only states what it returns, not when to choose it over alternatives.
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 already declare read-only, idempotent, and non-destructive behavior. The description adds a source URL and return type (DataFrame) but does not disclose update frequency, data limitations, or any query caveats. With annotations covering safety traits, the added context is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact, consisting of a title, a source URL, and docstring-style lines. Every element serves a purpose, with no redundant prose, and the structure makes the tool's core information immediately accessible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 sufficiently covers the parameter, return type, and data source. However, since there is no output schema, it would benefit from more detail about the returned DataFrame's columns, date range, or update cadence to fully support the agent's expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' with a default value, while the description clarifies that the parameter accepts a country name and provides the example 'China'. Since schema description coverage is 0%, the description effectively compensates for the missing schema documentation of this single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Economic Policy Uncertainty Index) and its parameter (country name), and the URL links to the authoritative source. However, it lacks an explicit action verb like 'fetch' or 'download', so the purpose is inferable rather than directly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related article_* tools, macro tools, or other EPU sources, nor does it describe conditions where this tool would be preferred. The URL and parameter definition are reference material, not usage direction.
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 already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the source URL but does not describe the output structure, whether the symbol changes columns/rows, or any rate limits. This is adequate but not rich, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and follows a clear docstring structure: title, parameter with choices and type, source URL, and return type. No filler words or redundant content. Every line adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations, a description that lists the parameter values, provides the return type, and cites the source URL is largely complete. The only minor gap is not describing the data format or how the parameter affects rows/columns, but given the simplicity and no output schema, this is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to compensate. The docstring explicitly lists the valid choices for 'symbol' (整体市场, 销量占比-PHEV-BEV, 销量占比-ICE-NEV), which are not present as enums in the schema. This is essential for correct use. It does not fully explain the meaning or output for each choice, but the labels are descriptive enough, so a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving CPCA new energy vehicle market segment data. The title '新能源细分市场' and the param choices (整体市场, 销量占比-PHEV-BEV, 销量占比-ICE-NEV) specify the resource and the type of data returned. While there is no explicit contrast with sibling tools, the unique '新能源细分市场' and 'fuel' context distinguish it enough from other car_market_* 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/5Does 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 lists the symbol parameter choices and the source URL but does not explain when to choose this over car_market_total_cpca or other car_market cousins, nor does it state any exclusions or prerequisites. Usage must be inferred entirely from the title and parameter hints.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds a source URL and return type but does not disclose any additional behavioral traits such as pagination, rate limits, or response format specifics. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a clear docstring-like structure with title, URL, parameter, and return sections. Each line serves a purpose and there is no redundant text. It is appropriately sized for a simple one-parameter tool, though the use of Chinese may limit accessibility for some agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 read-only annotations, but there is no output schema. The description only vaguely states the return as '统计数据-车型大类' (statistical data - vehicle category) without detailing columns or data structure. It also does not mention any date range or other nuances. Given the lack of an output schema, the description could be more informative about the returned DataFrame's contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a 'symbol' parameter with a default value and no description or enum. The description compensates by explicitly listing the valid choices ({"轿车", "MPV", "SUV"}) and the type as str, which is essential for the agent to invoke the tool correctly. However, it does not explain the meaning of these choices beyond their obvious Chinese labels, leaving some ambiguity for non-Chinese speakers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly indicate this tool provides CPCA (乘联会) statistical data for car market segments (级别细分市场), with a URL to the data source. The parameter choices (轿车, MPV, SUV) and return type (pandas.DataFrame) clarify its function. It is distinguishable from sibling tools like car_market_total_cpca (total market) and car_market_fuel_cpca (fuel-based) by focusing on vehicle segment/level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for fetching car market segment data, but it does not explicitly state when to use this tool versus its many siblings (e.g., car_market_cate_cpca, car_market_country_cpca). No exclusions or alternative tool references are provided. The parameter choices give some context, but the usage context is mainly inferred from the tool name and title.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is covered. The description adds that one request returns data at a specific moment and that the return type is pandas.DataFrame, which is useful context. It does not describe rate limits, pagination, or what specific fields are included, but given the simple read-only nature, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short sentences plus a URL and return type. It is front-loaded with the core purpose. The URL is arguably supplementary but not excessive. It earns a 4 rather than 5 because the first sentence closely repeats the annotation title, adding slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 parameters, the description should explain what data is returned (e.g., columns, supported coins, time precision). It mentions 'mainstream cryptocurrencies' and 'a specific moment' but does not detail the DataFrame's contents or whether it covers one coin or many. This leaves gaps for an agent deciding if this tool fulfills a request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the schema already fully defines the input. According to the rubric, 0 parameters merits a baseline of 4. The description adds no parameter-specific meaning, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides real-time market data for mainstream cryptocurrencies and returns a point-in-time snapshot. It distinguishes from sibling crypto tools by indicating 'spot' (实时行情) and referencing a specific data source. However, it lacks a strong action verb like 'list' or 'retrieve', making it less explicit than the highest standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for real-time cryptocurrency spot data, but provides no explicit guidance on when to use this tool versus alternatives (e.g., historical data tools like crypto_bitcoin_hold_report). No alternatives are mentioned, and no when-not-to-use conditions are stated.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a pandas DataFrame of historical data, which is useful, but it does not disclose rate limits, pagination, or error behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: source, URL, param, return, and rtype. It is compact and front-loaded with the main purpose. The URL and docstring-like formatting are slightly verbose but each element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 good annotations, the description is mostly adequate. It explains the return type and how to find valid symbols, but it doesn't clarify that it returns all available history (no date range) or describe output columns. This leaves minor ambiguity for new users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'symbol' parameter, so the description carries the full burden. It explains that symbol is a code, tells how to get all valid codes via ak.forex_spot_em(), and provides an example URL with EURCNY. This goes beyond the schema and gives actionable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical exchange rate data from East Money's forex market, using the phrase '历史行情数据' (historical market data). It distinguishes itself from spot-based siblings like forex_spot_em by the word '历史' and the URL example, though it doesn't 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use ak.forex_spot_em() to obtain valid symbol codes, which is a useful practical guideline. However, it does not explicitly state when to use this tool versus other forex or history-related siblings, nor does it provide exclusions or alternative recommendations beyond that.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds the data source (Eastmoney) and return type (pandas.DataFrame), plus the scope ('all rates'), which is useful context. However, it doesn't disclose any additional behavioral traits like pagination, update frequency, or potential issues, but with annotations present, the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single string containing the title, source URL, and return annotations. It is relatively concise and front-loaded with the key purpose. The inclusion of the URL and return type is useful, though the format is slightly unstructured. No unnecessary words, but it could be organized better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description should ideally explain what the returned DataFrame contains (e.g., columns like currency pair, price, change). It only says 'real-time market data' and the return type. This is adequate for a simple spot data tool but lacks detail about the returned fields, which could matter for an agent deciding how to use the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema is trivially covered. The description still provides context about the return content (real-time market data) and type (pandas.DataFrame), which adds meaning beyond the empty schema. For a zero-parameter tool, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing real-time spot data for all foreign exchange rates from Eastmoney.com, with a specific URL. It uses a specific verb ('实时行情数据' = real-time market data) and resource. While it doesn't explicitly differentiate from sibling tools like forex_hist_em, the 'spot' and 'all rates' scope makes the purpose reasonably 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving real-time snapshot data of all forex rates from Eastmoney, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., for historical data or specific currency pairs). No exclusions or alternative tool mentions are given, so usage 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only operation. The description adds the source URL and DataFrame return type, but does not disclose pagination, rate limits, or error behavior, providing only modest beyond-annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with source, parameter, and return sections. It is concise and front-loaded with the category, though the first line essentially repeats the tool title and URL, which adds minimal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 source, parameter, and return type, but lacks details on the returned DataFrame columns and any potential caveats. Since there is no output schema, the vague '定期报告-公告列表' leaves ambiguity about the actual data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description's explanation of 'symbol' as the fund code and its pointer to ak.fund_name_em() for obtaining valid values is essential and effective. It compensates for the schema gap, though it does not include format examples beyond the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves periodic report announcements from Eastmoney's fund page, specifying the source URL and DataFrame return type. It distinguishes from sibling tools like fund_announcement_dividend_em and fund_announcement_personnel_em by the '定期报告' (periodic report) keyword, though it lacks an explicit verb like 'fetch' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful hint to obtain the fund code via ak.fund_name_em() and indicates the return type. However, it does not explicitly state when to choose this tool over other announcement types or provide any exclusions, relying mainly on the tool name and category for usage context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds that it returns a pandas DataFrame and specifies parameter choices, but does not disclose behaviors like rate limits, data availability by date, or what happens with an empty date. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with a title, source URL, parameter documentation, and return type. It is concise and each section serves a purpose. The URL provides verification context without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and the return description only says 'pandas.DataFrame' without column details. The phrase '每日净值-实时行情' (daily NAV - real-time quotes) is somewhat ambiguous about whether it returns both daily NAV and real-time quotes. The parameter coverage is good, but the absence of return structure makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. The 'symbol' parameter is thoroughly documented with an explicit choice list and the meaning of empty string as 'all'. The 'date' parameter is only described as 'query date' without format or default explanation, though the schema shows a default of ''. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing real-time quotes for fund categories from the THS data center, with a source URL. It specifies the resource (fund data, daily NAV, real-time quotes) and distinguishes itself via 'category' in the name, though it does not explicitly state a verb like 'get' or 'fetch'. It is not a tautology and is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the parameter docs (symbol category and date), but does not explicitly state when to use this tool versus alternatives like fund_etf_spot_ths or fund_etf_category_sina. There are no exclusions or context about typical use cases, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description doesn't need to repeat those. It adds the return type (pandas.DataFrame) and the fact that it returns daily market data, which is useful. It doesn't disclose potential network dependencies or data availability, but with annotation coverage, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, composed of a title, source URL, and a lightweight docstring. It's properly scoped and avoids redundancy, though the information could be better organized with a leading action sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description covers the source, parameter acquisition, and return type. There's no explanation of the output columns, date range, or the exact symbol format, which leaves some ambiguity. Given the simplicity and annotation coverage, it's minimally sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and default, with 0% coverage. The description compensates by explaining 'symbol' as the fund name and pointing to fund_etf_category_sina() to obtain valid values. This gives the agent actionable guidance, though the term '基金名称' (fund name) slightly conflicts with the default value 'sh510050', which looks more like a ticker symbol.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving Sina Finance ETF fund daily market data ('日行情数据'), which clearly indicates its purpose. The 'sina' in both the tool name and description distinguishes it from similar East Money (em) fund history tools. However, it lacks an explicit verb and is phrased as a noun phrase rather than an action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the symbol parameter can be obtained via ak.fund_etf_category_sina(), providing a useful prerequisite for use. It does not, however, compare this tool to alternative historical data tools like fund_etf_hist_em or give explicit when-to-use/when-not-to-use guidance.
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 already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is useful, but it does not disclose behavioral details such as data frequency, columns, or network dependencies. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: source, URL, return description, and return type in a few lines. Every piece of text earns its place, and it is front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description provides the essential context: data source, entity type (on-exchange fund ranking), and output format (DataFrame). It lacks column details or update frequency, but given no output schema and no parameters, this is acceptably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The empty schema is fully described by itself, and with 0 parameters the baseline is 4. The description adds no parameter-related info because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool provides Eastmoney's on-exchange fund ranking data (场内交易基金排行) with a source URL and DataFrame return type. Though it lacks an explicit verb like 'get' or 'fetch', the noun '排行' and tool name make the purpose clear, and it can be distinguished from sibling fund ranking tools by the '场内' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling fund ranking tools (e.g., fund_hk_rank_em, fund_fh_rank_em). It does not state any exclusions, prerequisites, or alternative tools, leaving the agent without context for tool selection.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context by specifying the return type (pandas.DataFrame) and the underlying URL, but it does not disclose other behavioral traits such as data volume, pagination, or any special handling. This adds some value beyond annotations but remains limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three lines: a title identifying the data category, the source URL, and the return type. Every line adds useful information without redundancy. It is front-loaded with the resource name and avoids any verbose or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description adequately states what it returns (fund dividend ranking) and where it gets it from. It mentions the return type is pandas.DataFrame but does not describe the columns or ranking criteria. Given the simplicity of the tool, this is reasonably complete, though a bit more detail about the DataFrame structure would be beneficial for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any parameter semantics. With no parameters, the baseline score is 4 per the rubric, and the description correctly adds nothing about parameters. The input schema is empty and self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a fund dividend ranking from Eastmoney (天天基金网), with a URL pointing to the specific page and a return type of pandas.DataFrame. It explicitly states the resource (基金分红排行), making the purpose clear. However, it does not explicitly differentiate from sibling tools like fund_fh_em, though the 'rank' qualifier implies a ranking list rather than general dividend 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/5Does 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 provides the source and return type, without mentioning prerequisites, exclusions, or alternative tools. An agent has to infer the intended use solely from the tool name and the basic description.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the key behavioral disclosure that '该接口暂无数据' (this interface currently has no data), which is significant context beyond annotations. This transparency helps the AI agent avoid expecting real results, though it does not clarify if the data absence is permanent or transient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the source and the critical no-data warning. The included URL provides a useful reference but is somewhat long and could be considered noise. Overall, each line serves a purpose, and the structure is readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides the return type (pandas.DataFrame) and the data scope. However, the meaning of '该接口暂无数据' is unresolved, and there is no explanation of behavior when data is unavailable or whether the DataFrame is always empty. The absence of an output schema makes the description the primary source of return information, and it partially fills that role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there are no parameter semantics to explain. Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the source (东方财富网站-天天基金网), the resource (理财型基金收益), and the return (当前交易日的所有理财型基金收益). The verb 'returns' is implied in the docstring. However, the note '# 该接口暂无数据' introduces ambiguity about whether the tool actually returns data, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 among the many fund-related siblings. It does not mention any exclusions or alternative tools. The only potential signal is the 'no data' warning, but it is not framed as a usage instruction.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that the return type is pandas.DataFrame and that the data is historical net value details, which is useful but not extensive. It does not disclose pagination, data coverage, or any other behavioral nuances beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title line, a URL, and docstring-style param/return sections. It is structured and not verbose. However, the first line exactly repeats the annotation title, which is redundant and slightly wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description explains the data source (East Money/TianTian Fund), what the parameter means, and the return type. Yet it lacks details about the returned DataFrame's columns, date range, or any practical limitations. The absence of an output schema means the description should carry more return-structure information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that 'symbol' is a financial fund code obtainable via ak.fund_financial_fund_daily_em(). This adds the essential meaning and a useful cross-reference. It does not specify the code format or provide examples beyond the default, but it provides a functional description for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource as '理财型基金收益-历史净值明细' (financial management fund returns - historical net value details), which identifies what data is retrieved and distinguishes it from other fund-related siblings. However, there is no explicit verb like 'get' or 'fetch' – the purpose is stated as a noun phrase that mirrors the title, leaving the action implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when historical net value details for financial/wealth-management funds are needed. It also cross-references ak.fund_financial_fund_daily_em() to obtain the symbol, giving partial context. However, it does not explicitly state when to use this tool over sibling functions like fund_money_fund_info_em or fund_open_fund_info_em, nor does it provide exclusion criteria.
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 already declare read-only, idempotent, and non-destructive behavior, so the description's added context is limited to the specific time window (current trading day) and return type (pandas.DataFrame). There's no contradiction, but no deeper behavioral details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, followed by a source URL and return docs. The URL line adds provenance but is not strictly necessary for tool invocation; otherwise every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description covers what it returns and the data type, but lacks details about the DataFrame's columns, row granularity, or potential emptiness on non-trading days. The URL provides additional context but doesn't substitute for missing output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema describes everything needed. The description adds no param semantics because none exist; baseline 4 applies, as there is nothing to clarify or compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all graded fund net values for the current trading day, naming the resource and data source. However, it doesn't explicitly distinguish this from sibling tools like fund_graded_fund_info_em, leaving the 'daily' vs 'info' distinction implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the data scope ('current trading day'), but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention when not to use it or suggest a better sibling for other scenarios.
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 clearly declare this as read-only, idempotent, and non-destructive, so the safety profile is already established. The description adds minimal behavioral context: it names the source (Xueqiu/Danjuan), specifies the return type as pandas.DataFrame, and indicates the timeout parameter semantics. It does not disclose potential errors, data coverage, or pagination, but the read-only nature with annotations makes a 3 appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably compact but not optimally structured. It lacks a clear imperative sentence at the top; the first line is the title repeated. The URL adds contextual value but could be considered noise. The docstring-style parameter list and return line are efficient, but the overall structure is more like a technical docstring than a user-facing description. It earns a solid 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with good annotations and no output schema, the description provides sufficient context: it specifies the source, all three parameters with types and example values, and the return type (pandas.DataFrame). It does not enumerate the DataFrame columns, but 'holdings' is clear enough for a fund context. The lack of output schema is mitigated by the explicit return type, making this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero parameter descriptions (0% coverage), so the description carries full responsibility for explaining the parameters. It does so thoroughly: symbol is defined as 基金代码 (fund code), date as 财报日期 (report date), and timeout as a choice of None or a positive float. It also includes an example URL with concrete values (code=002804, id=103), which adds practical context beyond the schema. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title '雪球基金-持仓' (Xueqiu Fund - Holdings) and parameter names (symbol, date) make clear this tool retrieves fund holdings for a given fund code and reporting date. However, the description does not explicitly state 'Get holdings for a fund' in a complete sentence, relying primarily on the title and return type. It is distinct enough from siblings due to 'hold' in the name and the Chinese title, but not fully differentiated 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/5Does 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 are many sibling fund tools (e.g., fund_portfolio_hold_em, fund_hold_structure_em) with similar purposes, but the description does not mention any exclusions, prerequisites, or preferred use cases. It only lists parameters and return type, leaving the agent without context for tool selection.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety and idempotency are covered. The description adds that the tool returns a pandas DataFrame for the current trading day, which is some behavioral context. However, it does not disclose potential caveats such as network dependence, data update timing, or exact columns, leaving the description only partially informative beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title line, a URL, a return description, and a return type. Every element serves a purpose, and it is immediately clear what the tool does and what it returns. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with zero parameters and no output schema, the description provides the essential context: the data source, the scope (current trading day), and the return type (pandas DataFrame). It does not enumerate columns or limitations, but given the tool's simplicity and the existing annotations, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. Per the rubric baseline, 0 params warrants a score of 4. The schema already confirms no parameters exist, and the description adds no additional parameter context, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing money market fund return data from Eastmoney's fund page. It specifies the scope ('当前交易日的所有货币型基金收益数据' – all money fund returns for the current trading day) which clarifies what it does. It lacks an explicit verb but the return statement implies retrieval, and it distinguishes from sibling tools like fund_money_rank_em (ranking) and fund_money_fund_info_em (information) by focusing on daily return 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/5Does 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 only gives the source URL and return type, with no mention of when this is the appropriate choice compared to other money fund tools or any 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose behavioral traits such as data freshness, rate limits, or error conditions. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, URL, parameter list, and return type. It is front-loaded and each section serves a purpose, though the first line repeats the title without adding new information. Overall, it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and return type, which is enough for basic invocation. However, it lacks usage context, output column details, and references to alternative tools. Given the simple schema and strong annotations, this 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the indicator parameter has no enum in the schema. The description fully compensates by explaining each parameter: symbol is the fund code, indicator is a choice of '累计买入' or '累计卖出', and date is the query year. This is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as fund portfolio major changes from Eastmoney's fund archive, with a URL and parameter list. It clearly implies the tool retrieves major changes for a given fund, though it lacks an explicit verb like 'list' or 'fetch'. It is distinct from siblings like fund_portfolio_hold_em by name and resource path, but the description itself does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative fund portfolio tools. The description only provides parameter semantics and return type, with no mention of use cases, prerequisites, or exclusions.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful context about date format constraints, availability from 2017, and the pandas.DataFrame return type, which exceeds baseline without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with separate sections for source, parameters, and return type. However, the first line largely duplicates the tool name, and the URL could be considered extraneous for an agent's decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and safety annotations, the description adequately explains input format and data source. Missing information includes specific output columns, any pagination or size limits, and what differentiates it from similar fund report tools, leaving some ambiguity for an agent choosing among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'date' is fully explained in the description with allowed quarter-end format patterns and a start year, compensating for the 0% schema coverage. The schema only provides a default value, so the description adds critical semantics, though it doesn't explicitly mention the default or that the parameter is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as CNINFO fund industry allocation data via the path '巨潮资讯-数据中心-专题统计-基金报表-基金行业配置', distinguishing it from sibling tools like asset allocation and stock holdings. However, it lacks an explicit verb like 'retrieves' or 'queries', making it more of a title than an action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to select this tool versus alternatives such as fund_report_asset_allocation_cninfo or fund_portfolio_industry_allocation_em. It only describes parameter constraints and does not mention any exclusions or alternative tools.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds important behavioral context beyond this: the return type (pandas.DataFrame), the date format requirement, and the critical edge case that date ranges exceeding 6 months return an empty DataFrame with headers. This helps the agent anticipate failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring that is reasonably sized, but the opening title redundantly restates the tool name. The key behavioral constraint (6-month limit) is placed near the end rather than front-loaded. The URL adds reference value but could be omitted for brevity. Overall it is organized but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return type (DataFrame) and the edge-case behavior (empty DataFrame when range > 6 months), which covers the most critical aspects. It also states the data source and fund categories. However, it lacks column-level details (e.g., fund code, name, scale value) and doesn't discuss pagination or data update frequency, leaving some gaps for complex use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains start_date and end_date with format examples ('20260401') and symbol with allowed choices {'ETF', 'LOF', 'REITS'}. This compensates well for the bare schema, though it doesn't elaborate on the semantic range meaning beyond the labels 'start date' and 'end date'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides SZSE fund scale daily data ('深圳证券交易所-基金产品-基金规模-日频数据' and '返回: 深交所基金规模日频数据'). It identifies the resource (fund scale) and frequency (daily) despite lacking an explicit imperative verb like 'get' or 'fetch'. It implicitly distinguishes from siblings like fund_etf_scale_szse by supporting ETF, LOF, and REITS 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention when to prefer this over fund_etf_scale_szse or fund_scale_change_em. The date range limitation is disclosed but not framed as a usage criterion. There is no 'when not to use' or alternative tool references.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the source URL and allowed parameter values, but does not disclose behavioral quirks such as data freshness, pagination, rate limits, or potential errors. With annotations covering the main safety aspects, the extra context merits a middle score, but fails to provide deeper behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring format with title, URL, parameters, and return info. It is appropriately sized, though the Chinese text and redundant title phrase could be slightly streamlined. Overall, 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.
Completeness3/5Given 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, the description provides the parameter choices, source URL, and return type. However, it lacks details about the DataFrame structure (columns, index) and any caveats about the data (e.g., real-time vs historical). Since there is no output schema, this missing information leaves a gap in understanding what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'symbol' parameter (0% coverage) and no enum. The description fully compensates by listing all allowed values: '所有' and the six Chinese exchange names. This is essential for correct invocation. It also specifies the type as str, aligning with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides futures trading fees (期货手续费) from 9qihuo.com, with a URL and return type. It is specific about the data source and content, though it lacks an explicit verb like 'get' or 'retrieve'. It distinguishes from siblings by the unique source URL and Chinese title, but does not explicitly compare to similar futures fee tools such as futures_fees_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/5Does 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 lists the parameter choices and return type, with no mention of scenarios, prerequisites, or exclusions. No comparison to sibling tools is provided, leaving the agent to infer usage context.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict these. It adds the data source URL and return type (pandas.DataFrame), but does not disclose any additional behavioral traits such as date range limits or pagination. The additional context is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with a title, URL, parameter explanation, and return type. It avoids redundancy and front-loads the key information. The only minor issue is the repetition of '历史行情数据-日频率' but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data-retrieval tool with one parameter and no output schema, the description covers the data source, parameter semantics, and return type. However, it does not detail the DataFrame structure (e.g., columns like OHLCV) or date range, which would be helpful given the absence of an output schema. The presence of annotations and the URL partially mitigate this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name, type, and default value ('ZSD'). The description adds meaningful semantics: it explains that 'symbol' is a foreign futures code and points to a separate function for obtaining all valid codes. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides foreign futures historical daily data (外盘期货-历史行情数据-日频率). It identifies the resource and data frequency, though it lacks an explicit verb like 'get' or 'retrieve'. The name and sibling tools like futures_foreign_commodity_realtime and futures_foreign_detail suggest differentiation, but the description doesn't explicitly distinguish 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to obtain valid symbol codes by referencing ak.futures_foreign_commodity_subscribe_exchange_symbol(), which is a useful prerequisite. However, it does not explicitly state when to use this tool versus alternatives like real-time quotes or detailed foreign futures data, nor does it mention any exclusions.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds contextual value beyond annotations by specifying the exact source URL, the fact that it returns a pandas DataFrame, and the accepted symbol formats. It does not contradict annotations and provides useful additional 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring-like format, with title, URL, param, and return sections. It is appropriately sized for a single-parameter tool, though the URL is repeated twice and the structure could be streamlined. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with no output schema, the description provides the essential information: source, parameter semantics, and return type. It is sufficient for an agent to successfully invoke the tool, though it lacks details about date ranges or data structure. Given the simplicity, this level of completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'symbol' accepts both commodity codes and Chinese names, and points to a URL for the list of Chinese names. This adds some semantic meaning, but it doesn't explain the default value 'a', provide examples, or clarify what code format is expected, leaving gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves futures inventory data from Eastmoney's data center for a given symbol, as shown by '东方财富网-数据中心-期货库存数据' and ':return: 指定品种的库存数据'. It names the resource and source, but does not explicitly differentiate from sibling tools like futures_inventory_99 or futures_shfe_warehouse_receipt, so it lacks the sibling contrast needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only explains parameter input (supports codes and Chinese names) and provides a reference URL, but does not mention when this Eastmoney inventory data is preferable over other inventory tools. It fails to give any context for tool selection.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds valuable behavioral context: accepted date formats (YYYY-MM-DD, YYYYMMDD, datetime.date), default to current trading day, and return type pandas.DataFrame. This goes beyond what annotations provide and clarifies expected input flexibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a compact docstring style with a title line, source URL, and parameter/return documentation. It is not excessively verbose and each part is informative. The title line is slightly redundant with the tool name but serves as a clear subject statement, and the structure is logically organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter data retrieval tool, the description provides adequate context: the source URL, parameter semantics, default behavior, and output type. However, it does not describe the contents of the returned DataFrame (e.g., columns or meaning of settlement parameters), which could be useful for agents. Given the low complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'date' is thoroughly documented in the description with format options, default behavior, and accepted types. This fully compensates for the 0% schema description coverage and provides clear guidance for constructing valid inputs. The description also specifies the return type, adding further semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the Chinese title '上海国际能源交易中心-结算参数' which identifies the resource (Shanghai INE settlement parameters) but lacks an explicit verb like 'retrieve' or 'get'. It is more of a label than a functional statement, though the URL and parameter docs add some clarity. It does not explicitly distinguish from sibling tools like futures_settle_shfe or futures_settle_cffex beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 specific to the INE or compare with other futures_settle_* siblings. There are no preconditions, exclusions, or examples of appropriate use cases.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the source URL and how to obtain the symbol, and it states the return type (pandas.DataFrame). It does not disclose potential rate limits, data range, or column structure, but given the annotations, this is acceptable and adds some value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with title, URL, parameter docs, and return type. It is structurally clear and front-loaded with the main purpose. The long URL is somewhat extraneous but not harmful, and every sentence earns its place by providing invocation-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a relatively simple data-fetching function, and the description covers inputs and return type. However, with no output schema and no details about returned DataFrame columns, date ranges, or how symbols map to actual contracts, the description is not fully complete. It also lacks comparison with sibling tools for when to use it, leaving some ambiguity in a context-rich sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains both parameters: symbol can be obtained via match_main_contract and period is a choice with Chinese labels (1/5/15/30/60 minutes). This provides meaningful semantics beyond the schema's bare defaults, though it could benefit from examples of valid symbol formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '中国各品种期货分钟频率数据' (Chinese futures minute-frequency data), which clearly identifies the resource and frequency. The URL and 'return: 指定 symbol 和 period 的数据' further clarify it returns minute-level futures data for a given symbol and period. It distinguishes from daily or real-time siblings by specifying '分钟频率', though lacks a strong imperative verb like 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for acquiring the symbol parameter via match_main_contract(symbol="cffex") or a webpage, which is useful guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., daily or real-time futures data tools) or provide exclusions. The usage is implied: use when you need minute-frequency Chinese futures data.
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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds that the tool returns a pandas.DataFrame and specifies the exact source, which provides useful context about the data format and origin. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the key product term '外币对即期报价'. The URL and return annotations add value without significant fluff. The hierarchical path includes some redundant navigation, but it's not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return type (pandas.DataFrame) and source, but lacks detail about the actual data structure (columns, currency pairs, time dimensions). With no output schema, more specifics about the returned content would be helpful, though for a no-parameter read-only tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all inputs. The description doesn't need to explain parameters; the 0-parameter baseline of 4 applies, and no additional semantic gaps require compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns 外币对即期报价 (foreign currency pair spot quotes) from the China Foreign Exchange Trade System, with a source URL and return type. This identifies the resource and output clearly, though it lacks an explicit verb and doesn't differentiate from close siblings like fx_spot_quote or forex_spot_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. Among many FX-related siblings (fx_spot_quote, fx_swap_quote, forex_spot_em, currency_latest), the description gives no selection criteria, exclusions, or context about the specific data source beyond the name.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds behavioral details beyond annotations: it reveals the return format (pandas DataFrame with columns indexes, value, trans_date), provides a concrete data example, and lists valid name values. This additional context about output structure and parameter domain is valuable and not present in the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains useful content (index list, return example) but is structured as a docstring with redundant type annotations (e.g., ':type url: str') and a lengthy return example. It is not front-loaded; the Chinese title and parameter documentation precede the main value proposition. It is adequately sized but lacks polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains the return structure and sample data. However, it leaves gaps: the role of start_date is undocumented, the valid name values are listed but not explicitly mapped to the 'name' parameter, and there is no mention of pagination or row limits. It covers the essentials but is not fully complete for a 4-parameter tool with zero schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does list valid values for the 'name' parameter and identifies 'end_date' as the primary date parameter. However, 'url' is only described as '网址' (URL), and 'start_date' semantics are left unclear (empty default and no explanation of its relationship to end_date). The description adds some meaning but does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool obtains profit/loss details ('盈亏详情') for specified QHKC indexes and enumerates the valid index names (奇货黑链, 奇货商品, etc.), which is specific to the tool's purpose. However, it does not explicitly distinguish itself from sibling tools like get_qhkc_index or get_qhkc_index_trend, so it misses the differentiation that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by noting '指定 end_date 就可以了' (specify end_date only), implying the typical call pattern. However, it does not explain when to use this tool over alternative QHKC index tools or provide exclusions/prerequisites. The usage context 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: when start_date/end_date are empty, they default to today; when vars_list is empty, it returns all commodities. It also states the return type as pandas.DataFrame, which is helpful. It does not disclose data sources or update frequency, but given the annotations, the added defaults and return type earn a solid 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with clear sections for parameters and return, and it is appropriately sized for three parameters. It includes redundant ':type' lines that restate the schema types, but these are brief and not excessive. The structure is front-loaded with the purpose line, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly states the return type but does not explain the columns, data source, or the full scope of coverage (e.g., which exchanges or whether it aggregates all exchanges). Given the large sibling set of warehouse receipt tools, this lack of scope detail prevents an agent from confidently choosing this tool over exchange-specific ones. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It explains date formats (YYYY-MM-DD, YYYYMMDD, datetime.date), default behavior when empty, and gives examples for vars_list ('RB', 'AL'). However, there is a type inconsistency: the description says vars_list is of type str, while the schema declares it as an array. This could confuse an agent, keeping the score from being 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '大宗商品-注册仓单数据' (Commodities - Registered Warehouse Receipt Data) and the return type as pandas DataFrame, making it clear the tool retrieves warehouse receipt data. However, it does not explicitly differentiate itself from the many exchange-specific warehouse receipt siblings (e.g., futures_warehouse_receipt_czce), leaving its exact scope somewhat ambiguous. The verb 'get' in the tool name adds clarity, but the description is largely a noun phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the numerous alternative warehouse receipt tools among the siblings. It does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate. Blank default behavior is described (e.g., empty date means today), but this is parameter behavior, not usage context.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is well covered. The description adds some context via the source URL and return type (pandas.DataFrame), but does not disclose any additional behavioral traits such as authentication needs, rate limits, or time period coverage. This is consistent with annotations (no contradiction).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line for the title, a URL, and a standard :return:/:rtype: pair. There is no fluff or redundant explanation beyond the docstring's return type, which is conventional. It is front-loaded with the resource name and immediately provides the data source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, read-only, no output schema), the description is largely complete: it identifies the exact data product and its return type. It could elaborate on what the index measures (e.g., definition or units) or its update frequency, but the URL and title provide sufficient context for a basic data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is nothing to explain. Schema description coverage is 100% (vacuous), and the baseline for 0 params is 4. The description does not add parameter information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource: '财新数据-指数报告-新经济入职工资溢价水平' (Caixin Data Index Report – New Economy Entry Wage Premium), which distinguishes it from sibling index tools like index_ai_cx or index_nei_cx. However, it lacks an explicit verb ('get', 'fetch', 'return') in the main description; the :return: line implies retrieval but does not state the action directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is a bare title followed by a URL and return type, with no mention of use cases, prerequisites, or exclusions. Sibling tools are numerous (many index_*_cx variants), but the description offers no differentiation or selection advice.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and source URL but does not disclose any additional behavioral traits such as pagination, rate limits, or data 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, using a title, a relevant URL, and standard docstring entries for parameter and return. Every element contributes meaning without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the main points: source, parameter meaning, return type, and a default example via the URL. It does not explain how to obtain valid index codes or the exact columns of the returned DataFrame, but it is largely adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'symbol' parameter with no description, and schema description coverage is 0%. The description compensates by explaining that 'symbol' is the index code ('指数代码') with type str, which is essential. However, it lacks format examples or a code list, leaving some ambiguity about accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as retrieving index component stocks ('成分股') from Shenwan Hongyuan Research's index release details, with a specific URL and parameter. The resource is clear, but it lacks an explicit action verb (e.g., 'get' or 'fetch'), and it does not directly compare to sibling tools beyond the source name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only includes a parameter docstring and return type; there are no mentions of prerequisites, exclusion criteria, or other related 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?
Annotations already declare read-only and idempotent. The description adds return type (pandas.DataFrame) and parameter semantics, but not much else. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short, but the first line repeats the title from annotations, and the URL is arguably unnecessary. Nevertheless, it is structured with param/return docs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool promises 'specified date' components, but the schema has no date parameter. This is a critical gap; the agent cannot control the date. Also, no output schema, but the description says DataFrame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, so the description compensates by specifying that symbol is the index code and type str. It also provides an example URL. Could be improved with valid code range/format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns sample constituents for a specified date for the CNI (Guozheng) index, with a specific resource URL and return type. It distinguishes from sibling index tools by specifying the CNI index and 'sample details' domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives; it doesn't mention that it's for CNI index or exclude other index sources. There are many sibling index constituent tools, but no reference to them.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the data source URL and return type (pandas.DataFrame), providing some context beyond the annotations, but does not disclose other behavioral traits like update frequency or coverage of specific indices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It includes the source URL and return type in a structured docstring-like format, with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description adequately communicates that the tool returns a pandas DataFrame of real-time global index quotes. It names the data source and the specific data category, which is sufficient for a simple read-only tool. Additional column details or index coverage would be nice but are not critical for the tool's straightforward purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty schema), so there are no parameter semantics to explain. The description's mention of the return type adds value, and the baseline of 4 for no-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing real-time global index quotes from Eastmoney, with the specific resource (global indices) and data type (spot/real-time). It distinguishes itself from siblings like index_global_hist_em (historical) through the explicit '实时行情' (real-time) label, though it lacks an explicit verb like 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention that this is for real-time spot data while historical data would come from index_global_hist_em, nor does it reference any other related tools. The name implies real-time, but the description does not explicitly state usage context.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering behavioral safety. The description adds the return type (pandas.DataFrame) and the source URL, but provides no additional context like data granularity, update frequency, or special behaviors. It gives minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of a single line describing the index, a source URL, and return type. Every piece of information earns its place, and it is front-loaded with the tool's purpose. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, read-only, clear annotations, no output schema), the description is largely complete. It identifies the data source, the exact index name, and the return type. It could theoretically specify column names or data range, but these are not strictly necessary for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is complete (100% coverage), so no parameter explanation is needed. The description appropriately focuses on the output rather than parameter details, aligning with the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a specific index (配额内进口糖估算指数) from Mutian Tech, making the purpose understandable. However, it does not explicitly differentiate itself from closely related siblings like index_outer_quote_sugar_msweet or index_sugar_msweet, leaving some ambiguity for an agent comparing options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool vs alternatives. It does not mention related tools or exclusion criteria, relying solely on the tool name and description to imply its use case.
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 already declare readOnlyHint and idempotentHint. The description adds the return type (DataFrame), parameter choices, and source URL, but discloses no additional behavioral traits like data freshness or column details. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with title, URL, param, and return sections, but the first line repeats the tool's title. It is not overly long but includes redundancy and lacks a concise summary sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple real-time quote tool with one optional parameter and good annotations, the description provides sufficient context: source, parameter choices, and return type. It doesn't explain data columns or use cases, but the tool's narrow scope makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists the four allowed values for the symbol parameter, which the schema does not provide as an enum. Since schema coverage is 0%, this fully compensates and gives clear semantic meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides real-time quotes for fund indices from SWS Research, with a source URL. It doesn't use an explicit verb like 'get' or 'fetch,' but '实时行情' implies retrieval. It distinguishes from siblings like index_realtime_sw by specifying fund indices, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like index_realtime_sw or index_hist_fund_sw. The only usage info is the allowed parameter values, which addresses how to call it, not when.
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 already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), which is some context beyond annotations. However, it does not disclose other behavioral traits such as data range, update frequency, or any potential network dependencies beyond the URL. With annotations doing the heavy lifting, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, URL, return field, and return type. All information is front-loaded and relevant. There is no redundant text, and it earns its place by clarifying the data source and output format. This is a model of brevity without sacrificing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (0 parameters, no output schema), the description is largely complete: it names the resource, provides a URL, and states the return type. However, it lacks details on the data's temporal scope (e.g., historical range, frequency) or any notes on how the spillover index is calculated. These are not critical for a no-parameter tool but would enhance completeness. Annotations and the URL mitigate the gap, so a 4 is justified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100% (vacuously). The description correctly adds no parameter details because there are none. Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description also specifies the return type, which is useful for understanding the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '财新数据-指数报告-溢出指数' (Caixin Data - Index Report - Spillover Index) and states the return type (pandas.DataFrame) with ':return: 溢出指数'. This clearly indicates the tool returns the spillover index data, distinguishing it from sibling tools with different index names (e.g., index_dei_cx, index_ai_cx). However, the verb is implied ('return') rather than an explicit action like 'fetch' or 'get', so it lacks a strong action resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any selection criteria, prerequisites, or exclusions. There is no indication of when this specific spillover index tool is preferred over the many similar index_*_cx tools. This is a clear gap for an agent trying to choose among siblings.
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 already declare the tool read-only, idempotent, and non-destructive. The description adds the return type (pandas.DataFrame) and the data source URL, which is useful. However, it doesn't describe the DataFrame's columns, frequency, or any potential network dependencies, leaving some behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with each line serving a purpose: title, source URL, return value, and return type. It is well-structured and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides the essential information: the data source, the specific economic indicator, and the return type. However, without an output schema, it would benefit from describing the DataFrame's structure (e.g., columns) and historical range, which is absent. Still, it is adequate for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to clarify. The input schema is empty and sufficient. Per the rubric, 0 parameters gets a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Australia's Consumer Price Index yearly rate from Eastmoney, including a source URL. It distinguishes from sibling tools like macro_australia_cpi_quarterly by the 'yearly' qualifier in both the name and description. However, it lacks an explicit verb (e.g., 'get', 'fetch'), so it reads more as a title than a directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any conditions, exclusions, or related tools. The only context is the indicator name itself, which is insufficient given the large number of sibling macro 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), but does not disclose details about the data's content, frequency, or range, leaving the agent to infer the exact behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only the title, source URL, and return type. It is front-loaded with the essential identification, but the docstring format (':return:') is not tailored for agent consumption, and the URL is not functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema), the description provides basic adequacy but lacks detail on what the returned DataFrame contains (e.g., columns, time range, update frequency). The sibling tools for other Australian indicators are similar, so the agent might need more context to differentiate data contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the empty input schema accurately reflects that. The description adds no parameter information, but none is needed; the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching Australia's unemployment rate from Eastmoney economic data, distinguishing it from sibling tools covering other countries or indicators. However, it lacks an explicit action verb like 'fetch' or 'retrieve', relying on the name to convey the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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. The specific country and indicator in the name imply its use case, but there is no mention of exclusions or alternative tools for other data series.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a source URL and return type (pandas.DataFrame), which is useful context but does not describe pagination, rate limits, or data structure details. With annotations providing the safety baseline, the description's contribution 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a title line, URL, return name, and return type. It is front-loaded with the key information and contains no unnecessary elaboration. The title line somewhat repeats the tool name, but overall it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description provides the source URL and return type, which is a reasonable baseline. However, it does not clarify the DataFrame's columns, date range, or units, which could be important for an agent deciding whether this data meets a need. The indicator name is clear, but the completeness is only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the scoring rules, the baseline for 0 parameters is 4. The description does not need to explain any parameters, and it does not add anything beyond what the schema already implies (no parameters needed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly labels the tool as Eastmoney economic data for Canada's Consumer Price Index monthly rate, which identifies the resource and scope. It distinguishes from sibling tools like macro_canada_cpi_yearly by explicitly specifying '月率' (monthly rate). However, it lacks an explicit verb (e.g., 'get' or 'return'), though the URL and return statement imply retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like macro_canada_cpi_yearly or macro_canada_core_cpi_monthly. The name and description imply usage for monthly CPI data, but no exclusions or alternative references are provided. This is borderline between implied usage and no guidance, so a 3 is appropriate.
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 already declare the tool as read-only, idempotent, and non-destructive, covering safety. The description adds the data source URL and the return type (pandas.DataFrame), which is useful context. However, it does not describe the structure of the returned data, frequency, or any potential edge cases, so it only partially goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, a source URL, and a return type declaration. Every line provides relevant information with no fluff. It is front-loaded with the data name and source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, read-only, no output schema), the description provides adequate information: it identifies the data, the source, and the return type. However, it does not specify whether the DataFrame contains historical time series, what columns are included, or the data frequency, which could leave some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty schema), so there are no parameter semantics to explain. Per the rubric, a zero-parameter tool receives a baseline score of 4. The description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing China's total retail sales of consumer goods data from East Money (东方财富). The name itself is highly descriptive, and the return type (pandas.DataFrame) confirms it retrieves data. However, it lacks an explicit verb like 'get' or 'fetch' and does not explicitly differentiate from other macro_china_* tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other macroeconomic data tools. It simply states the data source and return type. There is no mention of use cases, exclusions, or alternative tools, leaving the agent to infer from the tool name alone.
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 already declare the tool as read-only, idempotent, and non-destructive, so the description doesn't need to repeat those. It adds the data range (19820201 to present) and return type (pandas DataFrame), plus a source URL, which is useful context for a zero-parameter 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key information: what the tool reports, the date range, a source URL, and the return type. Every line serves a purpose and there is no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter, read-only tool, the description provides the essential context: the exact data series, its timeframe, and the return format. It stops short of listing specific DataFrame columns, but the domain and title make the content predictable enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the baseline is 4. The description correctly doesn't describe any parameters, and there's nothing missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a report of China's export year-over-year change in USD, with a specified data range. It distinguishes from sibling macro indicators like imports or trade balance. However, it largely restates the tool's name, so it doesn't add much new information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 compared to alternatives such as macro_china_imports_yoy or macro_china_trade_balance. The usage context must be inferred entirely from the name and domain knowledge.
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 already declare read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat that. It adds concrete details: the data source URL and output as a pandas.DataFrame. However, it does not disclose any additional behavioral traits like update frequency, data granularity, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact, containing only the essential components: data source, URL, return content, and return type. There is no redundant text or filler, and all lines contribute value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only tool with annotations and no output schema, the description provides enough information to select and invoke it correctly. It states the source, content, and output type. It lacks details on the DataFrame structure (columns, time range), but this is not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the description is not required to explain parameters. The baseline score for 0-parameter tools is 4, and the description does not introduce any ambiguity or missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Hong Kong unemployment rate) and source (Eastmoney official data), and explicitly states the return type (pandas.DataFrame) and content (失业率). It distinguishes this tool from sibling macro tools by naming the specific region and indicator, though it lacks an explicit action verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., other Hong Kong macro indicators like CPI or PPI). There are no prerequisites or context hints about suitability for specific queries. Usage is only implied by the tool name and data description.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context beyond annotations: the data range (19810201-now), source URLs, and return type (pandas.DataFrame). It does not contradict any annotations and provides additional non-obvious information about the data source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core meaning. It includes source URLs and return type in a structured format. The URLs add some clutter but are not excessive. The sentences are short and every part has a purpose (definition, source, output type).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides essential context: data range, source, and return type. However, it does not specify the data frequency (e.g., monthly, yearly), column names, or any caveats about the data (e.g., seasonality, adjustments). This makes it minimally complete but with notable gaps for an agent that needs to interpret the returned DataFrame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides no parameter descriptions, so the description does not need to explain parameter semantics. The baseline for 0 params is 4, and the description adds context about the return type and data range, which is sufficient. There is no missing parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides China's trade balance in USD with a specific date range (19810201-present). It distinguishes itself from sibling tools like macro_usa_trade_balance or macro_uk_trade by explicitly mentioning China and USD. However, it lacks an explicit verb (e.g., 'get', 'retrieve'), so it reads more as a noun phrase than an action 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/5Does 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 what it returns, with no mention of suitable scenarios, prerequisites, or exclusions. Unlike the calibration high example, it doesn't name alternative tools or provide decision criteria.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the source URL and returns type pandas.DataFrame, which is useful context but does not disclose additional behavioral traits like data update frequency or field specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting only of a title, a URL, and return type annotations. Every line carries essential information, and there is no redundant content. The front-loaded title immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema), the description is largely complete. It identifies the data source (National Bureau of Statistics), the frequency (monthly), and the returned value. Some minor details like date range or column names are absent, but the tool is simple enough that these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered. The description adds meaning by explicitly stating the return type and the data returned (城镇调查失业率), making the tool's purpose clear without needing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the urban surveyed unemployment rate from National Bureau of Statistics monthly data, with a specific title and return type. It is distinct from sibling macro tools that cover other economic indicators, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor does it mention any exclusions or preferred contexts. It only lists the data source URL and return type, leaving the agent to infer usage from the title.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds a source URL, exact date range, and pandas.DataFrame return type, which goes beyond annotations. However, it does not disclose columns, update cadence, or potential data 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: main description, data interval, source URL, and return type are all in three short lines. There is no redundant filler or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless report retrieval function, the description adequately covers what data is returned, the source, and the time range. Since there is no output schema, it leaves column details and units unspecified, but this is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so schema coverage is effectively 100%. No parameter explanation is needed, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource clearly as the SPDR Gold Trust holdings report with a specific date range (20041118-present) and includes a source URL. It distinguishes the tool from siblings by naming the world's largest gold ETF. However, it lacks an explicit verb like 'fetch' or 'query', relying instead on a noun phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no exclusions, prerequisites, or alternative tool mentions. The description only states data content and range, which gives no explicit usage context.
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 already declare read-only, idempotent, open-world, and non-destructive behavior, so the description doesn't need to restate those. It adds the source URL, return type, and data range, which is useful context beyond the schema. However, it doesn't disclose potential pitfalls like rate limits or response structure variation, so it provides only minimal additional behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a clear main statement, a source URL, and docstring-style return info. Each line adds value, though the structure is slightly awkward due to the embedded docstring syntax. It's concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter, no-output-schema context, the description covers the source, data range, and return type. However, it doesn't specify the columns or granularity of the holdings report (e.g., daily records, fields like date and holding amount). This is a notable gap for an agent deciding whether the output meets its needs, so a 3 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 doesn't need to explain parameters, and it doesn't attempt to add any. The empty schema is consistent with this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a holdings report (持仓报告) for the world's largest silver ETF, with a specific data range (20041118-present) and return type (pandas.DataFrame). It identifies the resource and purpose, though it doesn't contrast with sibling tools like macro_cons_gold. There is a minor inconsistency (SPDR Gold Trust is actually a gold ETF, not silver), but the intent is still 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for retrieving silver ETF holding reports. The description provides the data source and date range, giving context for when it might be used, but it offers no explicit guidance on alternatives or exclusions. Since the name and description make the use case obvious, a score of 3 is appropriate.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds data range and source URLs, but does not disclose potential issues like data update frequency, error behavior, or whether the returned Series is historical or just the latest value, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with each line serving a purpose: the report name, data range, source URLs, and return type. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description provides sufficient context: data range, sources, and return type. It does not mention the series index (e.g., dates) or the exact frequency of releases, but these are inferable from the tool name and data range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description does not need to explain inputs. It adds value by describing the return type (pandas.Series) and the units (%), which helps the agent understand the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '欧元区CPI年率报告' (Eurozone CPI annual rate report) and specifies the data range and return type, making the tool's purpose clear. It distinguishes from sibling tools like macro_euro_cpi_mom by using '年率' (YoY) in the description, though it lacks an explicit action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or compare with sibling tools such as macro_euro_cpi_mom. Only the data range and source URLs are given, which are not usage guidelines.
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?
Annotations already declare read-only and non-destructive behavior. The description adds valuable context beyond annotations: data sources (8 platforms), instrument coverage, and the meaning of the report. It also clarifies the return type (DataFrame). This goes beyond the baseline annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated and redundant. The opening definition is repeated verbatim in '名词释义'. The long currency list and trading strategy section add bulk without helping an agent invoke the tool. While it has some structure with headings and a docstring block, the repetition and extras violate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only date-range query tool, the description covers the data content, sources, and return type reasonably. However, it lacks critical invocation details like date format, whether start/end are inclusive, and what columns the DataFrame contains. The typo in end_date further incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the param meaning. It only says both start_date and end_date are '具体交易日' (specific trading days) without specifying the format (likely YYYYMMDD from defaults) or the relationship between them. The end_date description contains a confusing typo ('与 end_date 相同'), leaving the semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the Jin10 FX speculative sentiment report, showing long/short position ratios from 8 platforms across 11 currency pairs and gold. This verb+resource+scope definition distinguishes it from sibling tools like forex_hist_em or currency_time_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for FX sentiment analysis through its detailed content explanation and trading strategy, but it never explicitly states when to use this tool versus alternatives. No exclusions or alternative tool mentions are present, so the 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, ensuring the agent knows this is a safe read operation. The description adds the data source (East Money) and return type (pandas.DataFrame), which provides context beyond the annotations without any contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a title, source URL, return value, and return type. Each line has minimal waste, though the URL is somewhat noisy and the return statement essentially repeats the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify return values. It provides the return type and a generic name for the data series, but it does not specify columns, date range, or frequency. For a simple no-param data retrieval tool, this is minimally viable but leaves some ambiguity about the DataFrame's structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 there is no parameter ambiguity. The baseline of 4 applies, and the description correctly does not need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data (Japan national core CPI yearly) via its title and return statement, and it distinguishes from sibling tools like macro_japan_cpi_yearly by specifying 'core'. However, it lacks an explicit action verb like 'fetch' or 'retrieve', relying on the docstring 'return' to imply the tool's behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, exclusions, or comparisons with other macro economic data tools, leaving the agent to infer usage solely from the tool name and title.
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?
Beyond the annotations (readOnly, openWorld, idempotent), the description adds only a source URL and return type. It does not disclose data coverage, update frequency, or potential limitations. With annotations already covering safety, the description provides minimal additional 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-structured; it consists of a title, a URL, and return annotations. It front-loads the main purpose but lacks explanatory sentences. It is not verbose, yet it reads more like a label than a crafted description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides the essential details: source, indicator, and return type. However, it omits information about the data's time range, frequency, or columns, and does not differentiate it from the many similar macro tools. It is minimally complete but not rich enough for easy selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema fully covers this aspect. The description supplements with the return type (pandas DataFrame) and the specific indicator name, which adds useful semantic context. Baseline for zero parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Eastmoney Swiss economic data) and the specific metric (consumer price index yearly rate). It distinguishes from sibling tools by naming the country and indicator explicitly. The verb is implied but unmistakable given the tool naming convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: to retrieve yearly CPI data for Switzerland from Eastmoney. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. It relies on the name and title to convey usage context.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame) but does not disclose any side effects or limitations. This is adequate but not rich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the title, a source URL, and return type. Every part contributes information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only data retrieval, the description provides the key facts: the data (Swiss GDP annual rate), the source (East Money URL), and the return format (DataFrame). It omits columns or date ranges, but these are not essential for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered and the description does not need to explain any input semantics. Per the guideline, a baseline of 4 is appropriate for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: Swiss GDP annual rate from East Money, and the intended data type is stated. It implies a data retrieval operation, but lacks an explicit action verb. The name 'GDP 年率' distinguishes it from sibling tools like macro_swiss_gdp_quarterly, though this is indirect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other Swiss macro tools or alternatives. The description simply states the data source and return type without any context, exclusions, or comparisons to siblings.
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?
注释已声明只读、幂等、非破坏性，描述补充了数据区间（20080220-至今）和返回类型（pandas.DataFrame），这有助于代理理解输出格式和时间范围。未发现与注释矛盾之处。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述简短但存在冗余：第一行与注解标题完全相同，:return 又重复了报告名称。URL 和返回类型是有效信息，但整体上重复度较高，不够精简。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于无参数、无输出模式的简单工具，描述已提供数据范围、返回类型和数据源URL，基本足以让代理理解该工具的功能和输出。虽然未给出具体列名或单位，但在该复杂度下已算完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式为空，参数数量为0，根据规则基准分为4。描述无需解释参数，且没有多余信息，符合无参数场景的预期。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
未提供任何使用场景或与替代工具的对比。在众多 macro_usa_* 兄弟工具中，没有说明何时使用此工具而非其他（如房屋开工、新屋销售）。仅有描述性内容，隐含用途但缺乏明确的when-to-use指南。
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 already declare readOnly, idempotent, and non-destructive behavior, so the description only adds minor context: the data range, a source URL, and the DataFrame return type. This is useful but does not disclose deeper behavior like units, frequency, or column structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core meaning, followed by a source URL and return type. Some redundancy exists ('美国经常帐报告' appears multiple times), but the overall structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description only says the return is a DataFrame containing the current account report. It lacks details about columns, units, release schedule, or how the data is structured, which would help an agent use the result effectively. It is adequate for a simple zero-parameter tool but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the input schema is trivially complete. The description adds no parameter details, but none are needed. The baseline of 4 applies because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a US current account report with a data range, clearly distinguishing it from sibling macro tools like macro_usa_trade_balance or macro_euro_current_account_mom. Though no explicit verb like 'get' or 'fetch' is used, the resource and scope are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the name and title (retrieve US current account data), but there is no explicit guidance on when to choose this tool over alternatives. It does not state exclusions or provide comparative context among the many macro_* siblings.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds meaningful context: the data range, the return format (current value %), and the pandas DataFrame return type. It also includes a source URL for reference, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of three lines: a title/data range, a source URL, and a return annotation. It is efficiently structured, though the first line is somewhat redundant with the title annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description provides essential details about data coverage, return unit, and return type. However, it is ambiguous whether the returned DataFrame contains the full historical series or just the latest monthly value, since the date range suggests the former while '今值(%)' implies the latter. With no output schema, this ambiguity remains unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so schema description coverage is trivially 100%. The description does not need to document parameters but does add value by explaining the return value is the current value in percent, which is helpful for an agent invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as '美国工业产出月率报告' (US Industrial Production Monthly Rate Report) and specifies the data range from 19700101 to present. The return annotation clarifies it outputs the current value in percent. However, no explicit verb like 'get' or 'retrieve' is used, and it relies on the tool name to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling macro_usa_* tools. It does not mention alternatives, exclusions, or typical use cases. The only signal is the tool name itself, which may differentiate it but is not explicit.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the data range from 19940201 to present and specifies the return type as pandas.DataFrame, which is useful context. It does not elaborate on data columns or update frequency, but for a no-parameter, read-only report this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it includes redundant :return: and :rtype: lines that essentially repeat the first sentence. The URL adds source context but could be removed or integrated without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool that returns a DataFrame, the description provides the essential facts: what data is included (Challenger enterprise layoffs), the time range, and the return type. It lacks a breakdown of columns or caveats, but given the simplicity and lack of output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is vacuous at 100%. No parameter explanation is needed, and the description appropriately avoids inventing details. A baseline score of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the U.S. Challenger enterprise layoffs report with a specific date range, distinguishing it from sibling macro indicators. However, it lacks an explicit action verb like 'returns' or 'gets,' and the first sentence essentially repeats 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/5Does 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 macro_usa_non_farm or macro_usa_initial_jobless. The description does not mention any exclusions, comparisons, or context for choosing this specific report.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the data range (1992-03-01 to present) and the return type (pandas.DataFrame with current value in %). No additional behavioral traits like rate limits or authentication are mentioned, but with strong annotations the description provides reasonable extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering the resource, data range, a source URL, and return type. Every element earns its place, and there is no redundancy or filler. The front-loaded first sentence immediately states the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool, the description is complete enough. It specifies the data range, the return value (current value %), and the return type (pandas.DataFrame). The absence of an output schema is mitigated by the clear return description. Minor gaps like exact column names or units are not critical for this simple use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 semantics, and it correctly focuses on the return value and data coverage. No parameter information is missing or misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the US retail sales monthly rate report and specifies the return value as the current value (%). The data range from 19920301 is also stated, which helps distinguish it from other macro indicators. However, it lacks an explicit verb like 'get' or 'retrieve', relying on the noun-phrase style common in 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 Guidelines2/5Does 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, no mention of exclusions, and no reference to sibling tools. The description merely states what data is returned and the date range. Usage context is only implied by the tool's name, which is not sufficient for clear guidance.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false; the description adds that the return is a time-series pandas DataFrame, that the index reflects population movement scale, and that administrative boundary includes districts/counties/towns/villages. It does not mention data source reliability, rate limits, or failure behavior, but the added context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with purpose, source URL, and param/return docs, but includes a long Chinese definition and URL that could be trimmed. The information is front-loaded and no obvious filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description explains the return type (pandas DataFrame) and index meaning, but it omits details like date range, column names, data frequency, and potential errors. For a two-parameter tool this is mostly adequate, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining area accepts province or city full names and indicator is move_in/move_out with Chinese meanings. It adds type and return info, though it could be more concrete about accepted name formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the migration scale index (迁徙规模指数) reflecting move-in/out population scale for a given area, with a URL naming Baidu Qianxi. It specifies the scope (province/city) but does not explicitly differentiate from the sibling migration_area_baidu, so it's clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter semantics (area can be province/city and requires full name; indicator values map to move_in/move_out) and mentions it's cross-city comparable, but it doesn't state when to prefer this over alternatives or provide exclusion criteria. Usage 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe query. The description adds the concrete return structure (dict mapping symbol to list of contract codes) and a real example, giving the agent useful context about response shape beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is functional but somewhat cluttered: a Chinese heading, a URL, and docstring-style parameter/return lines. It is not overly long, but the structure could be cleaner with an English summary and less repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description is reasonably complete. It lists all valid symbols and provides an example return value. Missing are notes about the default value (though present in schema) and how the resulting contract codes might be used as inputs for other option tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description for the symbol parameter), so the description must compensate. It fully enumerates the 15 acceptable symbol values and shows an example output, adding substantial meaning beyond the bare schema definition. However, it does not explain that the parameter is optional or how to interpret the returned contract codes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns '当前可以查询的期权品种的合约日期' (contract dates for currently queryable commodity options), and provides a complete list of valid symbols plus an example return dict. This clearly identifies the resource and action, though it does not explicitly distinguish it from sibling tools like option_commodity_contract_table_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative option contract tools. The description lists symbol choices and shows the return format, but does not mention under what conditions this tool is preferred, nor any exclusions or chaining with other 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety and idempotency. The description adds the return type (pandas.DataFrame) and the source URL, providing some behavioral context. However, it does not disclose further behavioral details such as data update frequency, limitations, or potential large response sizes. This is acceptable given the annotations but adds only marginal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title, URL, return type, and return format. It is well-structured and contains no unnecessary words. Every component serves a purpose, making it easy for an agent to quickly parse the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), strong safety annotations, and the presence of a return type, the description covers the essential facts: what it is, where the data comes from, and what it returns. It does not detail the exact columns or data semantics, but for a no-parameter read-only data retrieval tool, this is sufficient. The output schema is absent, so the return type mention helps fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully defines the call interface. The description does not need to explain any parameters, and with 100% schema coverage, the baseline for parameter semantics is 4. The description adds no parameter-related info, which is fine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing '期权价值分析' (option value analysis) from a specific source (东方财富网) and includes the URL. This clearly indicates the resource and the operation (retrieving data). However, it lacks an explicit verb like 'get or 'retrieve', and while it distinguishes from siblings by name, it does not explicitly state what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other option-related tools (e.g., option_premium_analysis_em, option_risk_analysis_em). It does not mention any context, prerequisites, or alternative tools, leaving the agent to infer usage from the name and source.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) but does not disclose other behavioral traits like data availability, historical scope, or any rate limits, which is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose statement, a reference URL, and clear parameter documentation in list form. Every element serves a purpose without redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description specifies the return type (pandas.DataFrame) and indicates that it returns the selected rate data, but it does not describe the DataFrame structure or columns. For a relatively simple data-fetching tool with no output schema, this is reasonably complete, though a brief example or column note would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates by listing explicit choices for market, symbol, and indicator, including examples like 'Shibor人民币' and '隔夜'. It also clarifies the return type. This adds substantial meaning beyond the bare schema properties and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool fetches interbank lending rate data for a specific market, instrument, and indicator from East Money. It uses a specific verb (拆借利率数据) and resource, but does not explicitly differentiate from sibling tools that also provide rate data, such as macro_china_shibor_all or repo_rate_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor does it state exclusions or prerequisites. It only describes the data it returns and provides parameter choices, leaving usage context entirely implied.
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 already declare readOnlyHint, idempotentHint, and non-destructive nature, so the bar is lower. The description adds minimal extra context: the source URL and return type (pandas DataFrame). It does not mention permissions, rate limits, or any special behaviors, but provides a bit of practical information about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, URL, and return type. Every line earns its place by providing essential information about the data source and output format. There is no redundancy or fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description provides a clear indication that it returns historical data as a pandas DataFrame and identifies the source. It could mention the exact columns or typical usage, but for a read-only data fetch with no inputs, this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema coverage is 100% (vacuously), and there is nothing to add. This justifies a baseline score of 4 as per the rubric for tools without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing historical data for the Shanghai Gold Exchange silver benchmark price, with a source URL. It specifies the resource and the fact it returns historical data, but does not explicitly contrast with sibling tools like spot_golden_benchmark_sge or spot_quotations_sge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply names the data source and return type, with no mention of scenarios where it is preferred or not recommended. The context of historical data is implied but not explicitly linked to similar 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?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds the source URL and the return type (pandas DataFrame), which is useful context, but it does not disclose any additional behavioral traits such as pagination, rate limits, or error behavior. This meets the baseline for a simple read-only 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, containing only a title, source URL, and return type. There is no wasted text, and the key information is immediately visible, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description adequately conveys that it returns a pandas DataFrame containing the SGE variety table and provides the data source URL. While it does not enumerate the columns or describe the table structure in detail, the name and context make the purpose sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 there are no parameter semantics to explain. The description is not required to compensate for any schema gaps, meriting the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the variety table (品种表) from the Shanghai Gold Exchange (SGE) market data section, identifying a specific resource and returning a pandas DataFrame. However, it does not explicitly differentiate this from other SGE-related tools like spot_quotations_sge or spot_hist_sge, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no explicit exclusion criteria. The description simply states what it returns, leaving the agent to infer the appropriate use case on its own.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds marginal context by specifying the return type (pandas.DataFrame) and the source URL, but it does not disclose potential latency, data delay, or other behavioral nuances. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, stating the core purpose first, followed by the source URL and return type. Every line earns its place, with no redundant text. It is very easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only spot quote tool, the description covers key aspects: data source, market segment, data type, and return format. The explicit return type compensates for the lack of an output schema. It does not detail the DataFrame columns, but this is a minor gap for such a simple fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema correctly reflects this with an empty properties object (100% schema coverage). Since there are no parameters, the description does not need to explain them. The baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides real-time quotes (实时行情) for Beijing A-shares (京 A 股) from East Money (东方财富网), with a source URL. This distinguishes it from sibling spot tools like stock_cy_a_spot_em and stock_sh_a_spot_em. However, it lacks an explicit action verb, using a noun phrase instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative spot quote tools. It does not mention any exclusions, preconditions, or alternative tools. An agent must infer usage from the tool name alone, which is insufficient given the large sibling set.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds the return type (pandas.DataFrame) and a source URL, but does not disclose additional behavioral traits like data freshness, column structure, or error behavior. With annotations present, the incremental value is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise lines: a Chinese title, a reference URL, and a return type. It is front-loaded with the source and purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description provides the essential return information: a pandas DataFrame of concept board names. It does not list columns or indicate total count, but it is adequate for a basic list retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema fully covers this (100% coverage). Per rubric, a parameterless tool receives a baseline of 4; the description adds no parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning concept board names from East Money's market center, specifying the source and board type. It distinguishes from siblings like stock_board_industry_name_em by the '概念板块' (concept board) keyword, though the verb ('list', 'retrieve') is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any context such as prerequisites or typical use cases. It is a self-contained no-parameter fetch, but the description does not state scenarios 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the data source URL and return type (pandas DataFrame), which provides useful context but does not disclose additional behavioral traits like data update frequency, potential limitations, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the essential information: data source, market, return type, and a reference URL. Every line earns its place, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is fairly complete. It states what it returns (real-time quotes), the source (East Money), and the specific market (ChiNext). It could mention that it covers all ChiNext stocks, but that is implied by the board scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description correctly reflects a no-parameter operation. With 0 parameters, the baseline is 4, and the description adequately avoids introducing any ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing real-time quotes for the ChiNext (创业板) market from East Money, with a specific URL source. It distinguishes from sibling spot tools by naming the specific board, though it does not explicitly list alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus other similar spot tools (e.g., stock_sh_a_spot_em, stock_sz_a_spot_em). The description lacks any context about selection criteria or exclusion cases.
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 already declare read-only, idempotent, and non-destructive behavior, so the description only needs to add extra context. It adds the source URL and the return type (pandas.DataFrame), which are useful but minimal. No additional behavioral traits (e.g., data freshness, pagination, or error conditions) are disclosed, but the safety profile is well-covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line naming the data source, the URL, and a return type annotation. Every element is purposeful, and it is front-loaded with the tool's identity. There is no redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool, the description covers the essential functional context: the source (East Money), the specific page, and the output type. The term '市场统计表' is somewhat vague regarding exact columns or time coverage, but given the simple interface and good annotations, the tool is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no parameter documentation burden. The baseline for 0-parameter tools is 4, and no further parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the East Money block trade market statistics table (东方财富网-数据中心-大宗交易-市场统计) and specifies the return type as a pandas DataFrame. However, it lacks an explicit verb like 'fetches' or 'returns' and does not explicitly differentiate from sibling block-trade tools such as stock_dzjy_mrtj or stock_dzjy_hygtj, though the '市场统计' scope provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its alternatives. It merely states the data source and output type without mentioning any relevant context, such as 'use this for overall block trade market summary' or 'for daily statistics use stock_dzjy_mrtj'.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return type (pandas.DataFrame) but does not mention any rate limits, pagination, or data freshness characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with all necessary component lines. The URL example is optional but not excessive; it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two simple parameters and an output schema is absent. The description specifies return type but does not enumerate which financial indicators are included, which could confuse an agent choosing among similar tools. Given the family context, more detail about the data content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides full parameter documentation: symbol is the stock code and indicator is a choice of '年度' or '报告期'. This adds meaning beyond the schema's type/default definitions, enabling correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Eastmoney HK stock financial analysis main indicators (东方财富-港股-财务分析-主要指标). It specifies the resource (HK stocks) and scope (main indicators), distinguishing it from A-share siblings like stock_financial_analysis_indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as stock_financial_hk_report_em or stock_financial_analysis_indicator. The description only covers parameter meanings, not selection criteria.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the source URL and return type but does not disclose additional traits like rate limits or data coverage. With strong annotations, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured as a docstring with a title, URL, parameter docs, and return type. It avoids redundant elaboration, but the return line repeats the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description only states 'pandas DataFrame' without describing columns or data structure. Parameters and defaults are covered, but behavioral specifics (e.g., how many periods, data availability) are missing. This is a moderate gap for a financial data tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents all three parameters with Chinese explanations and explicitly lists allowed values for symbol (资产负债表/利润表/现金流量表) and indicator (年度/报告期), which the schema lacks. This significantly improves parameter understanding, though stock code format is only implied by the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching East Money HK stock financial statements (三大报表), with a source URL and return type. It distinguishes from siblings by specifying HK stocks and the three major statements, though it lacks an explicit action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for HK stock financial statements via its title and parameter choices, but does not explicitly state when to use this tool over alternatives or provide exclusions. No 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-established. The description adds the source URL and return type (pandas.DataFrame), which is useful, but it does not disclose behavioral details such as whether the result is aggregated, how invalid symbols are handled, or any pagination/rate-limit behavior. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring pattern: title, URL, param, return. Each line contributes essential information without redundancy. It is slightly terse and not front-loaded with an English action sentence, but it remains efficient and well-structured for a data-retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 strong read-only annotations, the description covers the parameter choices and return type. However, there is no output schema, and the description does not detail the DataFrame's columns or the meaning of 'teamwork' synergy, leaving uncertainty about the result structure. It also lacks guidance on selecting this variant over closely related siblings, making it minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'symbol' with a default of '社保' and no description. The description fully compensates by explicitly listing the allowed choice set: {"全部", "个人", "基金", "QFII", "社保", "券商", "信托"}, and clarifies the parameter is a string. This is critical for correct invocation and far exceeds the schema's minimal information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (东方财富网, Eastmoney) and the specific dataset: 股东协同-十大流通股东 (shareholder synergy top 10 circulating shareholders). It includes the URL and return type, making the tool's resource explicit. However, it lacks an explicit action verb like 'fetch' or 'list', and while it distinguishes from siblings via 'free' and 'teamwork' in the title, it does not explicitly contrast with the many similar holding-analysis sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the numerous sibling tools such as stock_gdfx_free_holding_analyse_em, stock_gdfx_holding_teamwork_em, or stock_gdfx_free_top_10_em. The description only states the data source and parameter choices, leaving the agent to infer the appropriate context. No exclusions or alternative recommendations 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds the data source URL and parameter scoping but does not disclose additional behavioral traits such as rate limits, output size, or error handling, which go beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, including only the title, URL, parameter documentation, and return type. It is front-loaded with the resource name and avoids unnecessary filler, though the inline URL and docstring format are slightly unstructured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should provide more detail about the return structure, but it only states '高管持股' and pandas.DataFrame without column or time-range information. The single parameter is well-covered, but the output remains underspecified for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by enumerating the valid values for 'symbol' and labeling it as a choice. It clarifies the allowed options and their apparent meaning, though it does not explicitly describe how each value affects the returned DataFrame.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as executive holdings data from Eastmoney's data center, with parameter choices indicating filtering by all, increases, or decreases. However, it lacks an explicit verb like 'get' or 'fetch' and does not differentiate from sibling tools that also deal with stock holdings data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parameter choices ('全部', '股东增持', '股东减持') imply distinct usage scenarios, and the data source URL gives context. Yet it does not explicitly state when to use this tool versus alternatives or provide any prerequisites or exclusions, relying on the reader to infer intent.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds the source URL and return type (pandas.DataFrame), but does not disclose data granularity, update frequency, or any potential quirks. With annotations present, this is adequate but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three lines with no fluff: a human-readable title, the source URL, and the return type. Every element earns its place, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data-fetch tool with strong annotations, the description is largely complete: it names the data source, the specific dataset, and return format. The only gap is the lack of detail on the DataFrame's columns or structure, but this is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. The description correctly notes the return type, which is useful, and the baseline of 4 applies since no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource clearly: Eastmoney data center's equity pledge industry data for listed companies. It distinguishes from sibling tools like stock_gpzy_individual_pledge_ratio_detail_em by specifying '行业数据' (industry data), but lacks an explicit verb such as 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 use cases, prerequisites, or comparisons to sibling equity pledge tools, leaving the agent to infer suitability only from the name.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the Sina Finance source URL and states it returns a pandas DataFrame, but provides no details on edge cases, rate limits, or data limitations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is structured and compact, using standard :param format. It repeats the Chinese title that appears in annotations and includes a full URL that may be superfluous, but the overall length is appropriate and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return value's structure, but it only says '指定 indicator, stock, date 的数据' without specifying columns or data fields. It adequately covers the query parameters and return type, but leaves the agent uninformed about what the returned DataFrame actually contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully documents all three parameters: indicator with explicit choices ('分红', '配股'), symbol as stock code, and date with a concrete format example ('1994-12-24'). This completely compensates for the schema gap and goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving dividend and rights issue details from Sina Finance for a specific stock, date, and indicator. It provides a concrete source URL and names the exact data domain (分红配股详情), distinguishing it from the broader sibling stock_history_dividend by its indicator options and date-specific detail focus. However, it does not explicitly contrast itself with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are any prerequisites or exclusions mentioned. The description simply lists parameters and the return type, leaving the agent without context for selecting this tool over similar dividend/rights 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a pandas.DataFrame and references a source URL, but it does not disclose additional behavioral traits such as rate limits, error handling, or data scope beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, URL, parameter, and return type. It is front-loaded and each line serves a purpose, though the URL is arguably optional and could be omitted for brevity. Overall, it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 explains the return type as 'financial indicators' in a pandas.DataFrame, but it does not specify which indicators are included or their format. This is adequate for basic usage but leaves ambiguity about the data contents, especially given the description's brevity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, symbol, with no description. The description explicitly states 'symbol: 股票代码' (stock code) and provides a default example via the URL (code=03900). This adds semantic meaning beyond the raw schema, though it does not detail the expected format or possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool retrieves financial indicators for Hong Kong stocks from East Money via the title '东方财富-港股-核心必读-最新指标' and the parameter/return documentation. It distinguishes itself by specifying '核心必读' (core reading) and '最新指标' (latest indicators), though other HK financial tools exist among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when financial indicators for a specific HK stock are needed, based on the provided purpose. However, it does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusion criteria or when-not-to-use scenarios.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context such as the data source URL and the return type (pandas.DataFrame), but does not disclose behavior like date inclusiveness, timezone handling, or potential limitations of the data source. It adds some value but lacks deeper behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured as a docstring, with each parameter on its own line and a clear source URL. Every line provides useful information without unnecessary fluff. The structure is easy for an agent to parse, though it lacks a brief narrative overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters and no output schema, the description covers the parameters and return type, but omits important details such as the exact columns of the returned DataFrame, the date/time format expected for start_date and end_date, and how the period interacts with daily minute data. The unusual default values (e.g., '1979-09-01 09:32:00') are not explained, leaving ambiguity for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists parameters with defaults and no descriptions, so the description carries the full burden. It provides per-parameter documentation: symbol (股票代码), period (choice of '1','5','15','30','60'), adjust (choice of '','qfq','hfq'), start_date (开始日期), and end_date (结束日期). The valid choices for period and adjust are explicitly listed, which is essential. However, date formats are not specified, and the odd default values are unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing daily minute-level (分时) quotes for Hong Kong stocks from Eastmoney, with the title '东方财富网-行情-港股-每日分时行情'. The resource and data type are specific, and the tool name 'stock_hk_hist_min_em' aligns with the description, distinguishing it from daily or spot HK stock tools. However, the verb is not explicitly stated (e.g., 'fetch' or 'get'), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: provide a HK stock symbol, a minute period, adjustment, and date range to retrieve minute-level history. However, it does not explicitly state when to use this tool versus alternatives like stock_hk_hist (likely daily) or stock_hk_spot (real-time). No exclusions or when-not-to-use guidance is 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds that the return is a pandas.DataFrame and the source URL, but does not disclose behaviors like rate limits, invalid symbol handling, or data update frequency. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, starting with a title line, then a URL, then docstring-style param/return/type lines. Every line contributes meaning and the content is front-loaded. The mix of Chinese text and docstring syntax is slightly noisy but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description covers the parameter format and return type, but it does not specify the output structure (columns, date range, etc.) beyond 'historical trend'. For a simple read-only tool with annotations, this is adequate but not complete; an agent might not know what fields to expect in the returned DataFrame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema property 'symbol' has no description and a default of '00700'. The description explains the symbol must be a '带市场表示的证券代码' (securities code with market representation), reinforced by the URL example 'HK_00700'. This adds critical meaning beyond the schema. However, the default '00700' appears inconsistent with the market-prefix requirement, creating mild ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '东方财富-个股人气榜-历史趋势' (Eastmoney individual stock popularity ranking historical trend) and states the return is historical trend data for a specific stock. The URL example and sibling names (e.g., stock_hk_hot_rank_detail_realtime_em, stock_hk_hot_rank_latest_em) help distinguish this as the historical trend variant, though the description does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when historical popularity trend data for a specific Hong Kong stock is needed, via the '历史趋势' phrase and the return type. However, it provides no explicit when-to-use vs alternatives, no exclusions, and no mention of sibling realtime or latest variants.
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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the return type (pandas.DataFrame) and the data source URL, but does not disclose additional behavioral details such as pagination, error handling, or the exact ranking criteria.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured, with a title, example URL, and param/return blocks. Every line adds value and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description provides the return type and a URL, but the lack of an output schema means more detail on the returned DataFrame columns would be valuable. The market scope (HK) is implied by the name and URL, not explicitly stated in the description itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining the symbol parameter as a 'security code with market representation' and providing the example 'HK_00700'. This adds meaning beyond the bare string type, though it lacks detail on supported market prefixes or format variations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves the latest popularity ranking for individual stocks from East Money, with a Chinese title and example URL. It distinguishes itself from sibling tools like 'stock_hk_hot_rank_em' by specifying 'latest' and 'hk' in the name and URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives is provided. The URL example and 'HK' hint at Hong Kong stocks, but there's no mention of exclusions or referenced sibling tools for other markets or ranking types.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds context about the accepted date range (from 20170331) and the date format pattern (quarter-end dates), which is useful. However, it does not disclose what columns the returned DataFrame contains, whether any parameters are required, or any potential edge cases (e.g., empty results for unsupported dates). Given the annotation coverage, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring structure with param, type, return, and rtype sections. It includes a URL for source reference, which is useful but not strictly necessary. The use of Chinese title and docstring is efficient and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with good annotations, the description covers the core usage. However, it leaves ambiguity about the scope of the returned data (whether it applies to all A-shares or a specific stock) and does not describe the DataFrame columns. No output schema exists, so the description should carry a bit more burden here. It is minimally viable but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'date' as a string with a default, providing no semantic meaning. The description compensates fully by specifying the exact format (XXXX0331, XXXX0630, XXXX0930, XXXX1231), the start date, and the type. This is clear, actionable guidance that goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's scope: retrieving shareholder count and holding concentration (股东人数及持股集中度) from CNINFO's thematic statistics. It specifies the data source via URL and the return type as a pandas DataFrame. It is not a tautology, but the Chinese title serves as the primary description and lacks an explicit English verb like 'retrieve' or 'query', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 compared to similar sibling tools such as stock_zh_a_gdhs or stock_hold_change_cninfo. It does not mention alternatives, exclusions, or specific scenarios. The only usage-related context is the date format and availability start date, which is parameter guidance rather than tool-selection guidance.
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 already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false, covering the safety profile. The description adds that it returns a pandas DataFrame and includes the source URL, which is useful context. It doesn't disclose any additional behavioral traits like pagination, rate limits, or data update frequency, but it doesn't contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is formatted as a structured docstring: endpoint title, URL, market notes, parameter specs, and return type. It is relatively compact and front-loaded with the main purpose. The market notes are somewhat redundant and could be trimmed, but overall each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with no output schema, the description covers the return type and parameter choices adequately. However, it doesn't list the actual fields in the returned DataFrame, nor does it explain the relationship between the symbol parameter and the market codes mentioned. With many similar sibling tools, the lack of comparative guidance is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It provides types and examples for all three parameters: symbol with valid choices, start_date with format '20200713', and end_date similarly. The market=001/003 lines reference a parameter not in the schema, which could mislead, but the core parameter semantics are clearly explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving daily individual stock statistics for Shanghai-Shenzhen-Hong Kong Stock Connect holdings. The source URL and market code hints (001/003) provide specific scope. However, it does not explicitly differentiate from sibling tools like stock_hsgt_hold_stock_em or stock_hsgt_individual_em, relying on the name to distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage details: symbol choices ('北向持股'/'南向持股'), date format examples, and return type. It implies the tool is for querying a specific data range, but it doesn't say when to use this tool versus alternatives among the many Stock Connect siblings. The market codes are mentioned but not mapped to any schema parameter, which creates ambiguity.
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?
Annotations already declare read-only, idempotent, and non-destructive hints. The description adds that a valid login token (xq_a_token) may be required and that an APIError is raised for invalid login states, which is useful behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is reasonably concise and follows a standard structure with parameter/return/exception sections. It includes a useful example URL. Minor redundancy exists in the type declarations, but overall every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks details on the market scope (HK stocks) and the contents of the returned DataFrame. It also doesn't explain how to obtain the token or any limitations. Given there is no output schema, more explicit return field documentation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the docstring explains each parameter: symbol is a securities code, token is the Xueqiu xq_a_token, and timeout sets the timeout period. The return type is specified as a pandas DataFrame, which adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool retrieves a company profile ('公司简介') for an individual stock, with a sample URL (00700). However, it doesn't explicitly distinguish this from the A-share or US versions of the same tool; the differentiation relies on the tool name containing 'hk_xq'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling tools (e.g., stock_individual_basic_info_xq for A-shares, stock_individual_basic_info_us_xq for US, or stock_hk_company_profile_em). The only hint is the tool name, which is not elaborated in the description.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, conveying the read-only and idempotent nature. The description adds context about the data source (Eastmoney Data Center) and the time scope ('近期', meaning recent), but does not disclose other behaviors such as rate limits, data truncation, or possible empty results. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a compact docstring format with title, URL, parameter definitions, and return type. It is reasonably concise, though the URL is arguably non-essential and the Chinese title is repeated. Overall, it is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, parameters, and return type (pandas.DataFrame), but the output details are vague — it does not specify the columns or interpretation of '资金流数据'. With no output schema, this leaves the agent guessing about the returned data structure. It is minimally complete for a simple query tool but lacks richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains both parameters. It defines 'stock' as 股票代码 (stock code) and 'market' as the exchange with explicit allowed values: sh, sz, bj for Shanghai, Shenzhen, and Beijing. This goes well beyond the schema's type and default, giving the agent everything needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving individual stock fund flow data from Eastmoney's data center, with the title '东方财富网-数据中心-资金流向-个股' and the return statement '近期个股的资金流数据'. The resource and scope are specific, though it lacks an explicit verb like 'get' and does not differentiate from the nearby sibling 'stock_fund_flow_individual'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions, prerequisites, or scenarios where another sibling tool would be more appropriate. The only hints are the URL and parameter definitions, which do not constitute usage guidance.
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 already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context about the auth requirement (raises APIError when login state is needed) and the return type (pandas.DataFrame). However, it does not disclose data fields, rate limits, or other behavioral nuances, leaving the description to rely heavily on the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear :param/:return/:raises sections and is appropriately concise. The only minor flaw is the duplication of the title at the top and the absence of a one-line summary before the docstring details, but overall it is efficient and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple spot-quote tool, the description covers the essential aspects: symbol scope, auth requirement, and return type. However, since there is no output schema, the '证券最新行情' return is only minimally described; an agent would benefit from more detail on the fields or examples of symbol formats to avoid ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description thoroughly documents all three parameters: symbol (with specific security code types), token (xq_a_token), and timeout (None or positive float). This fully compensates for the schema's lack of explanatory text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching the latest security quote from Xueqiu ('证券最新行情'), supported by the title and example URL. It explicitly lists supported symbol types, which adds clarity, though it lacks a single concise sentence that states the tool's primary verb and 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/5Does 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 the many sibling spot-quote tools (e.g., stock_zh_a_spot_em, stock_us_spot). The description only lists supported symbol types and mentions an authentication requirement, but does not explain selection criteria or exclude alternatives.
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 already mark the tool as read-only, idempotent, and non-destructive. The description adds the specific API endpoint (p_public0002) and return type (pandas.DataFrame), but does not mention pagination, rate limits, or data granularity, so behavioral insight is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized with a source link and reST-style parameter/return docs. It is front-loaded with the Chinese title and purpose, but the URL and verbose param list could be trimmed; still, each part serves documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the return is only described as a pandas DataFrame of '行业分类数据' (industry classification data), leaving the data structure and contents ambiguous. It also lacks examples or edge-case guidance, so the description is adequate but incomplete for an agent to fully predict the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a bare 'symbol' parameter with no description or enum. The description compensates by listing all eight valid industry standards, clarifying the parameter meaning as a string, and noting the default, which fully resolves parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it queries the p_public0002 interface for industry classification data (行业分类数据), giving a clear verb and resource. However, it does not explicitly differentiate from sibling industry tools like stock_industry_change_cninfo or stock_industry_pe_ratio_cninfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 documents the API endpoint and parameter choices, with no context 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific symbol choices and the fact that it returns a pandas DataFrame, but does not disclose further behavioral traits such as rate limits or the meaning of the return data. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title and URL. However, it includes a confusing return line '指定 indicator 的数据' which appears to be a template artifact and adds noise. Overall, it is appropriately compact for a simple tool but not perfectly clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description provides the parameter choices and return type, but does not explicitly describe the DataFrame contents (e.g., stock code and name), and the return line is ambiguous. Given the name suggests 'name_code', a more explicit mention of the output columns would improve completeness. Still, the essentials are present, so it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no enum values. The description compensates by listing the allowed symbol values: '主板A股', '主板B股', '科创板' with their corresponding codes, and specifying the type as str. This gives the agent the necessary semantic information to choose the correct parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides the title '上海证券交易所-股票列表' (Shanghai Stock Exchange Stock List) and a source URL, clearly indicating this tool fetches the SSE stock list. The verb is implicit rather than explicit (e.g., 'get' or 'fetch'), and it does not clearly distinguish from sibling tools like stock_info_a_code_name or stock_info_sz_name_code, though the exchange is named. Thus it is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lists parameter choices and a return type, with no mention of suitable use cases, exclusions, or references to sibling tools. This is 'no guidance' per the rubric.
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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context: data availability starts from 2005, the quarter encoding scheme, and the return type (pandas.DataFrame), but does not disclose pagination, rate limits, or the actual columns/scope of the returned table.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the main purpose, followed by the URL and docstring-style parameter/return notes. The URL may be unnecessary for an agent, and the return line simply repeats the tool name, but overall every sentence carries useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool, the description covers invocation and parameter semantics well. However, with no output schema, it does not describe the DataFrame's columns, row semantics, or which market/scope of stocks is covered, leaving the agent without a clear picture of the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description fully compensates by explaining the symbol format, the quarter-to-code mapping, and providing concrete examples like '20191' and '20193'. It also specifies the type as str, making the single parameter unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a Sina Finance institutional holdings overview table (机构持股一览表) and specifies the data source URL. However, it lacks an explicit verb like 'get' or 'fetch', and while the name suggests it is the overview variant, it does not explicitly contrast with sibling tools like stock_institute_hold_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_institute_hold_detail or stock_institute_recommend. The description only explains the symbol parameter format, leaving the agent to infer the tool's contextual role among many stock data 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?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds a source URL and return type (pandas.DataFrame), which provide minimal context about data origin and output format, but no additional behavioral specifics such as rate limits, data freshness, or failure modes. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief with three lines: title, URL, and return type. It is front-loaded with the key resource name and lacks fluff, though the URL is somewhat tangential. It is appropriately sized for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides only a high-level return type and source. It does not specify columns, data granularity, or how the data is structured. For a zero-parameter tool, this is minimally sufficient but leaves gaps for an agent that needs to interpret the returned DataFrame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description needs no parameter details. The schema coverage is trivially 100%, and the description correctly implies a no-argument call. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning IPO beneficiary stocks data from Tonghuashun (同花顺) Data Center, with a specific URL and return type. Though it lacks an explicit verb like 'get' or 'fetch', the resource and scope are unambiguous, and the name differentiates it from related IPO tools like stock_ipo_ths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the data name and description: the agent can infer it is for IPO beneficiary stock data from 10jqka. However, there is no explicit guidance on when to use this tool versus sibling tools, nor any mention of exclusions or alternatives.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and the direct source URL, which is useful but not extensive. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a docstring structure with param, type, return, and rtype lines. The included URL is slightly verbose but adds source context. No unnecessary filler; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description provides the essential return type and parameter meaning. However, it does not describe what 'new stock issuance details' actually contain, nor does it clarify the scope (e.g., only A-shares) or any data limitations. This would be sufficient for a basic understanding but not for nuanced tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'stock' is clearly explained as a stock code (股票代码), and the URL provides an example (600004). Since schema description coverage is 0%, the description fully compensates by defining the parameter's meaning and expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns new stock issuance details (新股发行详情) for a given stock code. This is a specific action and resource, though it does not explicitly differentiate from the many sibling IPO tools. The source URL (Sina Finance) helps identify the data origin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling IPO tools (e.g., stock_ipo_ths, stock_ipo_review_em). The description only implies usage via the stock parameter, without context on selection criteria or alternatives.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type but does not disclose additional behavioral context such as data scope, update frequency, or potential limitations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three lines covering the source, URL, and return type. No unnecessary words, each element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description provides the data source and return type, which is fairly complete. However, it lacks detail about the exact data fields or whether the data is historical/current, but this is acceptable given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (vacuously). The baseline for 0-param tools is 4, and the description doesn't need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning '新股上会信息' (IPO review meeting information) from East Money's data center, with the URL and return type making the purpose evident. It distinguishes from sibling tools like stock_ipo_declare_em by specifying '上会' (review meeting), but the verb is implied via ':return:' rather than an explicit 'Get' or 'List'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other IPO-related tools. There is no mention of alternatives, exclusions, or specific use cases beyond the data source itself.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent correctly knows this is a safe, non-mutating operation. The description adds the parameter meaning (days: 5/10/30/60) and the return type (pandas.DataFrame), but does not disclose any additional behavioral traits such as potential missing data, rate limits, or quirks of the Sina source. Given the annotation coverage, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a title, URL, and docstring-style :param:/:return: sections. It is concise and front-loaded with the purpose. The inclusion of the URL adds reference value but is not strictly necessary, and the return line repeats the title. Overall it is efficient and easy to parse, with only minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description adequately explains the parameter and return type. However, since there is no output schema, the description does not reveal what columns or structure the returned DataFrame will have, leaving the agent without full knowledge of the output. It also does not mention any context about the data source or what '上榜统计' includes beyond the title. This is a minimal but workable level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'symbol' parameter, so the description carries the full burden. The description fully compensates by documenting the valid choices and their meanings: '5' for recent 5 days, '10' for 10 days, '30' for 30 days, '60' for 60 days. This gives the agent everything it needs to correctly select a value, making the parameter semantics highly clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '龙虎榜-个股上榜统计' (Dragon-Tiger List individual stock listing statistics), which clearly states the tool's resource and the type of data it returns. It also provides a source URL and parameter details, making the purpose concrete. However, it does not explicitly distinguish this from the many sibling 'lhb' (Dragon-Tiger List) tools, some of which also deal with individual stock statistics, so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as stock_lhb_stock_statistic_em or stock_lhb_detail_em. There is no mention of prerequisites, scenarios, or which context calls for this specific 'ggtj' (individual stock statistics) variant. The only usage clue is the parameter choices, which are about time ranges, not about when to select this 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds the return type (pandas.DataFrame) and the data source URL, but it does not disclose additional behavioral details such as whether results are paginated, the exact columns returned, or any rate limits. This is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a logical docstring structure: title, source URL, parameter documentation, and return type. It avoids unnecessary prose, though the title is repeated at the start and in the annotations. Overall, it is appropriately sized and front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is adequate for basic invocation but lacks detail about the returned DataFrame's structure (columns, row semantics). It also does not clarify how this tool differs from the many sibling LHB tools, which is important given the large sibling set. The parameter meaning and return type are covered, but the data content and use case context are underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'symbol' with no description (schema coverage 0%). The description fully compensates by explaining that symbol is a choice of {'5': 最近 5 天; '10': 最近 10 天; '30': 最近 30 天; '60': 最近 60 天;}, providing clear semantic meaning for the allowed values. This single parameter is completely documented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '龙虎榜-机构席位追踪' (Dragon-Tiger List - Institutional Seat Tracking), which clearly identifies the resource. It lacks a direct action verb but the title plus the parameter options (recent 5/10/30/60 days) imply a historical data retrieval function. It partially distinguishes from sibling tools via '机构席位追踪' (institutional seat tracking) as opposed to other LHB variants, but does not 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus the many sibling LHB tools (e.g., stock_lhb_jgmx_sina, stock_lhb_jgstatistic_em). The description only includes parameter choices and a URL without context on use cases, prerequisites, or alternatives. The agent must infer applicability from the name alone.
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 already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds a return type (pandas.DataFrame) and the source URL, but discloses no other behavioral traits such as data update frequency, pagination, or potential inconsistencies. This adds some value but does not go beyond annotations in a significant way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and follows a structured docstring format (title, URL, param, return). However, the title phrase is repeated in the return line, and the whole description is a series of fragments rather than a coherent sentence, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not specify the columns or the precise content of the returned DataFrame. It provides the source URL and parameter semantics, but an agent would be uncertain about what specific statistics are included (e.g., count, amount, rank). Given the single parameter and simple nature, it is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, symbol, is fully explained in the description with a clear mapping of each value to a specific day range (5→最近5天, 10→最近10天, etc.). Since the input schema has 0% description coverage, the description completely compensates by providing all necessary interpretation context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource (龙虎榜-营业部上榜统计) and provides a direct data source URL, indicating it returns statistics on securities department rankings for the Dragon Tiger List. It distinguishes from other LHB tools by focusing on statistical aggregates, though it lacks an explicit action verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The parameter choices (5/10/30/60 days) imply time-range selection, but there is no mention of preferred use cases, exclusions, or comparison with other stock_lhb_* 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that the return type is a pandas.DataFrame and that it contains the most-appearances ranking, plus a source URL. It does not disclose additional behavioral traits like pagination or rate limits, which is acceptable given the annotations, but the content 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title line, a URL, and a return type/description. All three elements carry useful information and nothing is redundant. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter data retrieval tool with rich annotations, the description covers the essentials: source, return type, and the specific ranking metric. While it could offer more context about what the data represents or how it is sorted, the existing information is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty. The baseline for 0 params is 4, and the description does not need to explain parameter semantics. It appropriately stays silent on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves data about business department rankings by number of appearances on the 龙虎榜 (Dragon-Tiger List) from 同花顺's data center. It specifies the exact metric ('上榜次数最多') and provides a source URL. However, it does not explicitly differentiate this tool from similar siblings like stock_lh_yyb_capital or stock_lh_yyb_control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any scenarios, prerequisites, or exclusions. The only added context is the source URL, which does not help an agent decide between this and similar ranking 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a source URL and parameter constraints (allowed symbol values) but does not disclose additional behavioral traits like rate limits, pagination, or data freshness. It does not contradict annotations; the query verb aligns with 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title as the first line, followed by a URL and docstring-style params. It includes a small redundancy: the return line repeats the title phrase '标的证券名单及保证金比例查询'. Overall, it is appropriately sized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query with two optional, defaulted parameters, the description covers the purpose, parameters, return type (DataFrame), and data source URL. It does not have an output schema, but the description sufficiently explains what the tool returns. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does provide docstring-style meanings: symbol is limited to {'深市', '沪市', '北交所'} and date is '交易日期' (trading date). However, it fails to specify the date format (though the default '20260113' hints at it) and does not describe the return DataFrame columns in detail. This partial compensation merits a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '融资融券-标的证券名单及保证金比例查询' (Margin trading - underlying securities list and margin ratio query). It specifies the resource (标的证券名单及保证金比例) and the action (查询), and distinguishes from sibling margin tools by covering three exchanges (深市/沪市/北交所) with a URL source. This matches a specific verb+resource pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or direct comparisons to sibling margin tools (e.g., stock_margin_sse). The usage context is only implied by the parameter choices, not explicitly stated.
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?
Beyond the read-only and idempotent annotations, the description adds the data source URL and declares the return type as pandas.DataFrame. It does not disclose potential rate limits, data granularity, or how the DataFrame is structured, but for a safe read tool the annotations already cover the main behavioral contract. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with four lines: title, source URL, parameter spec, and return spec. It is appropriately sized and front-loaded, with no filler. The structure is clear even though the language is Chinese.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool with no output schema, the description provides the necessary parameter choices and return type. However, it leaves ambiguity about the nature of the returned data (e.g., time series vs. snapshot, column names, frequency). This is a clear gap, though the tool is simple enough that the agent can likely infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description is the only source of parameter meaning. It explicitly enumerates the valid values for 'symbol' (上证, 深证, 创业板, 科创版), which is essential for invoking the tool correctly. This adds crucial semantics that the JSON schema entirely lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description explicitly state this returns P/B (市净率) data for a selected market (指定市场), with the URL indicating the source. It uses a clear resource and scope, distinguishing it from PE-focused siblings like stock_market_pe_lg. However, the verb (get/retrieve) is only implied via the return type, and the title mentions 'main board' while the symbol options include non-main-board markets, slightly muddying clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like stock_index_pb_lg or stock_market_pe_lg. It does not state prerequisites, exclusions, or scenarios. An agent would have to infer usage from the name and parameter choices.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the safety profile is clear. The description adds the data source URL and return type (pandas.DataFrame) but does not disclose additional behavioral aspects like data frequency, historical depth, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title, URL, and docstring-style param/return lines. It is not excessively verbose, though the URL and docstring formatting could be streamlined; the content is directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description covers the essential purpose and parameter. However, with no output schema, it fails to describe the structure or time span of the returned PE data, and the title's '主板' (main board) label conflicts with the inclusion of 创业板 and 科创版, creating mild ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a type and default for 'symbol' with no enum or description (0% coverage). The description compensates by explicitly listing the allowed values {'上证', '深证', '创业板', '科创版'} and the meaning of the parameter as the target market for PE data, making parameter semantics fully specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing PE ratio data for Chinese stock markets via the title '乐咕乐股-主板市盈率' and the return statement '指定市场的市盈率数据'. It is specific about the resource (market PE) but does not explicitly differentiate from sibling tool stock_index_pe_lg, which may serve a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as stock_index_pe_lg or stock_market_pb_lg. It only describes the parameter and return value, leaving selection criteria entirely to the agent.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only operation. The description adds the source URL and return type but discloses no additional behavioral traits such as rate limits, pagination, or authentication requirements. It does not contradict annotations, but the added context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter/return annotations, and type hints. It is well-structured and easy to parse. The title '同花顺-盈利预测' is somewhat redundant with the tool name, and the URL is specific to the default symbol 600519, which might be distracting, but overall each section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters, the description covers the essential inputs and return type. However, it does not explain what each indicator means or what columns the returned DataFrame contains. Since there is no output schema, this missing detail leaves the agent uncertain about the actual data structure, which could affect downstream processing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully documents both parameters. It specifies symbol as '股票代码' (stock code) and lists all valid choices for indicator, including exact Chinese strings like '预测年报每股收益' and '业绩预测详表-机构'. This is critical because the schema provides no enum values, making the description the only source for allowed inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing profit forecast data from 同花顺 (THS), with a source URL. The title '同花顺-盈利预测' and the return type 'pandas.DataFrame' make it evident this is a data retrieval tool. However, it lacks a strong imperative verb like 'Get' or 'Fetch', and the purpose is conveyed through the title and docstring rather than explicit action language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that stock_profit_forecast_em exists for East Money data, or provide any exclusion criteria. The only implied usage is via the parameter descriptions (e.g., indicator choices), but there is no context about typical scenarios or selection criteria.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the return type is pandas.DataFrame and provides the source URL, which is useful but does not disclose behavior such as data completeness, freshness, or any peculiarities of the ranking list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the titled source, URL, return label, and return type. Every element contributes, with no redundancy or filler. The docstring format is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, clear annotations, and a specific data type), the description adequately states what it returns and where the data comes from. It lacks column details, but for a basic ranking list with a recognizable Chinese stock-market indicator, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per guidelines, the baseline for 0 params is 4, and no parameter descriptions are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing data on '量价齐跌' (volume and price both falling) from 同花顺's data center technical stock selection, which distinguishes it from sibling rank tools. It includes a URL for the source and states the return type, making the purpose understandable, though it lacks an explicit action verb like 'fetch' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling stock_rank_*_ths tools. It only states what it returns without mentioning any context, prerequisites, 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose pagination, rate limits, or other behavioral aspects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the Chinese title, followed by the URL and docstring-style param/return lines. It contains some redundancy (the return line repeats '向上突破') and the format is a bit unstructured, but overall it is efficient and every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description covers the source, parameter choices, and return type. However, it does not describe the structure or columns of the returned DataFrame, which is relevant since no output schema is provided. It is minimally sufficient but lacks details that would help an agent know what to do with the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the parameter has no enum, so the description's explicit list of eight moving-average options (from '5日均线' to '500日均线') is essential. It also specifies the type as str. This fully compensates for the schema's lack of detail and is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as THS Data Center technical stock selection for upward breakout (向上突破), with a source URL. This distinguishes it from sibling rank tools like stock_rank_cxd_ths or stock_rank_ljqd_ths. However, it doesn't explicitly state the action (e.g., 'retrieves a list of stocks'), relying on the title concept to convey the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs other stock_rank_*_ths tools. The description only provides parameter options and a source URL, with no mention of alternatives, prerequisites, or specific use cases. The intended context is implied by the title but not stated.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds the source URL (https://data.eastmoney.com/bkzj/hy.html) and return type, but does not disclose rate limits, authentication, or any data behavior beyond the annotations. No contradiction, but limited additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear header (title/URL), structured :param and :return sections. The duplicate title line matches the annotation but is not overly wasteful. It front-loads the source path and parameter definitions without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters, the description provides parameter choices and a high-level return statement (pandas DataFrame of ranking data). However, it does not describe the DataFrame's columns or any nuances about the data (e.g., date handling, sorting), leaving some gaps given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by enumerating exact choices for both parameters: indicator accepts {'今日', '5日', '10日'} and sector_type accepts {'行业资金流', '概念资金流', '地域资金流'}. This adds semantic meaning that the raw schema (just string type and defaults) lacks, making parameter selection unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (sector capital flow) and the action (ranking) via the path '资金流向-板块资金流-排名' and the return '资金流排名数据'. It clearly indicates that this tool fetches sector fund flow ranking data. However, it does not explicitly differentiate from sibling tools like stock_sector_fund_flow_hist or stock_sector_fund_flow_summary, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 describes parameters and return value. The implied usage is for ranking data, but there is no when/when-not or alternative comparison, so it fails to direct an agent effectively.
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 annotations declaring readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, the safety profile is already clear. The description adds the source URL and return type but does not disclose additional behavioral traits such as data freshness, pagination, or potential scraping delays. It adds minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title and URL. It uses a structured docstring format with :return: and :rtype:, which is clear. There is some redundancy (the board name repeats), but overall it is concise without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter data retrieval tool with strong annotations, the description provides the source and return type but lacks details about the DataFrame's columns, data freshness, or any caveats (e.g., includes only currently listed delisted stocks). The absence of an output schema means the agent cannot know what fields to expect, making this description minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for 0 params is 4. The description appropriately does not attempt to explain any parameters, and there is no parameter information to add beyond the schema, which correctly defines an empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the '两网及退市' (two networks and delisted stocks) board from Eastmoney, with a specific URL. It states the return type as pandas.DataFrame, making it evident this is a data retrieval tool for that particular board. Though it lacks an explicit verb like 'fetch' or 'get', the :return: field implies retrieval, and the board name distinguishes it from sibling tools for other boards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by naming a specific board and providing a URL, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative recommendations are mentioned, leaving the agent to infer from the board name and sibling tool names that this is for 'two networks and delisted' data.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond a source URL and return type (pandas.DataFrame). It does not disclose rate limits, authentication, or quirks, but given the annotations, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, containing a title line, a URL, and return type. It is structured with label-like formatting. The first line is redundant with the annotation title, but overall it is efficient and front-loaded, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining the return value. It states it returns a pandas.DataFrame of the A-share goodwill market overview, but it does not describe columns, time periods, or granularity. Given the existence of several similar goodwill-related sibling tools, this lack of detail prevents full understanding of what data will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing to document. Per the rubric, 0 params warrants a baseline of 4, and the description correctly avoids inventing parameter details. The return type mention is not related to parameters but is harmless.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the A-share goodwill market overview from East Money's data center, with a source URL and return type. It does not explicitly state an action verb like 'get' or 'fetch', but the resource and scope are specific. It does not differentiate from sibling tools such as stock_sy_em, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool or mention alternative tools. The use case is implied by the name and description: if an agent needs A-share goodwill market overview data, this tool is appropriate. However, there are no exclusions, prerequisites, or alternative recommendations, so it stops at implied usage.
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 annotations already declaring readOnlyHint=true, destructiveHint=false, and idempotentHint=true, the description adds modest extra context: the data source (Eastmoney URL) and the return type (pandas.DataFrame). It does not disclose potential caveats like rate limits, pagination, or the exact output columns, but the safety profile is well covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a title, URL, parameter list, and return type. Each line serves a purpose and is not redundant, aside from the first line duplicating the annotation title. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description explains parameters and return type adequately. However, it does not enumerate the columns of the returned DataFrame (e.g., open, high, low, close, volume), which is significant given there is no output schema. It also omits date format details, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it does well: each parameter has a clear explanation, including the valid choices for `period` and `adjust`, and the important note that `symbol` must come from `stock_us_spot_em()`. The main gap is that date formats are not explicitly stated, though the schema defaults imply YYYYMMDD.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool fetches daily market quotes for US stocks from Eastmoney, with a source URL provided. It does not explicitly differentiate from sibling tools like stock_us_daily or stock_us_hist_min_em, but the function name and parameters (start_date, end_date, period) make the historical daily data purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical prerequisite: the `symbol` must be obtained from `ak.stock_us_spot_em()`'s `代码` field. However, it does not explicitly state when to prefer this tool over alternatives (e.g., minute-level history or spot quotes) or when not to use it. Usage is implied through the parameter choices and source, but no exclusions or comparisons are given.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the data source URL and the return type (pandas.DataFrame), but does not disclose any additional behavioral traits such as code format requirements, data update frequency, or potential limitations. It adds some value beyond annotations but is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight, structured docstring with title, source URL, parameter, and return type. Every line serves a purpose with no fluff or repetition. It is front-loaded with the title and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple, single-parameter, read-only data-fetching tool. It specifies the return type and data source, and the annotations cover safety semantics. It does not describe output columns or edge cases, but for this level of complexity the information is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the 'symbol' parameter, but the description compensates by documenting ':param symbol: 股票代码' and ':type symbol: str'. The default value in the schema ('603392.SH') provides a concrete format example. This is sufficient for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving A-share equity structure data (股本结构) from Eastmoney, with a URL and return type confirming the purpose. It lacks an explicit verb like 'get' or 'retrieve', but the resource and scope are specific and distinguish it from generic stock 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/5Does 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 exclusions, prerequisites, or why this tool should be chosen over similar sibling tools like stock_zcfz_em or stock_zh_a_gdhs. The context is purely descriptive with no decision support.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the core safety profile is covered. The description adds valuable behavioral context by warning that large-scale scraping can lead to IP bans, which is a rate-limit risk. It also discloses the data source via URL, enhancing transparency beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: a one-line summary, a source URL, and structured docstring elements for parameters and return. It avoids redundancy for the most part, though the first line duplicates the annotation title. Overall, every part adds some value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, the description is minimally viable: it states the data is historical index quotes and returns a pandas.DataFrame. However, it does not specify columns, date ranges, or frequency, which are important for an agent to know what to expect. The source URL partially compensates by allowing lookup of the exact page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by explaining the parameter 'symbol' as an index code ('指定指数代码') with an example 'sz399998' and type str. This provides meaning beyond the raw schema property name and default value, though it does not enumerate valid symbol formats (e.g., sh/sz prefixes) exhaustively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool provides Sina Finance index historical market data ('新浪财经-指数-历史行情数据'), with a source URL and a specific symbol example. It identifies the provider (Sina) which distinguishes it from sibling tools like stock_zh_index_daily_em (Eastmoney) and stock_zh_index_daily_tx (Tencent), though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It includes a caution about IP bans ('大量抓取容易封 IP') but no context about preferred use cases, prerequisites, or exclusions. This leaves the agent without explicit usage direction.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the data source (Baidu), the data category (financial statements/valuation), and the return type (pandas.DataFrame). It does not disclose additional behavioral traits such as rate limits or permissions, but none are implied. The description is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a title line, an example URL, and a param list. Each element serves a purpose—the title states the domain, the URL shows the source, and the param docs explain inputs. It is slightly redundant with the tool name but remains efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should cover return structure. It states the return type as pandas.DataFrame and labels it '估值数据' (valuation data), but does not describe expected columns, index, or the effect of period choices. For a simple query tool, this is adequate but not comprehensive, leaving room for ambiguity about the returned data format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no enums, but the description fully documents all three parameters: symbol (股票代码), indicator (choice of five metrics), and period (choice of five ranges). It also provides defaults in the schema, and the description adds meaning by enumerating the exact allowed choices. It does not explain the meaning of each indicator or period, but the choices are self-explanatory for the domain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '百度股市通-A股-财务报表-估值数据' (Baidu Stock Connect A-share financial statement valuation data), with an example URL. It distinguishes from siblings like stock_hk_valuation_baidu and stock_us_valuation_baidu by specifying 'A股' (A-shares). However, it lacks an explicit verb such as 'retrieve' or 'get', relying on the noun phrase to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (Baidu source, A-share market, valuation metrics) that implies when this tool is appropriate. It does not explicitly state when to prefer this over alternatives like stock_zh_valuation_comparison_em or stock_value_em, nor does it give when-not guidance. Usage is implied rather than direct.
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 already cover read-only, idempotent, and non-destructive behavior. The description adds context about the data source (Eastmoney), the specific quote page URL, and that the date parameter is a trading day, returning a pandas DataFrame. It does not disclose details like required date format, data columns, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the source and pool type, followed by a URL and a clear Python-style docstring for the parameter and return value. Every line adds needed information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description provides sufficient context for basic invocation: the source, the pool category, the date parameter's role, and the return type. It lacks only a clear explanation of the expected date format and a definition of '次新股', though the default value and tool name offer partial clues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a 'date' string with a default value but no description. The description compensates by documenting ':param date: 交易日' (trading day) and ':type date: str', which clarifies the intended parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '东方财富网-行情中心-涨停板行情-次新股池' (Eastmoney Market Center Limit-up Board Sub-New Stock Pool) and specifies the return as '次新股池', clearly indicating it retrieves the sub-new stock pool. It distinguishes from sibling pool tools by naming the specific pool type, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling pool tools (e.g., stock_zt_pool_em, stock_zt_pool_previous_em). It only states the source and return type, leaving the selection decision to inference from the name.
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 already indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns a pandas DataFrame and specifies the data source URL, but does not disclose any additional behavioral traits such as rate limits, data freshness, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, including a purpose statement, source URL, parameter definition, and return type in a few lines. It is not overly verbose, though the docstring format is slightly unstructured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter read-only nature and no output schema, the description provides enough to invoke the tool and understand its return type. However, it lacks specifics about the DataFrame columns or content beyond the generic '主营构成', which would help an agent know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and default, with no description. The description compensates by explaining that 'symbol' is a stock code with market identifier, and the URL example (SH688041) further illustrates the format. This adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves main business composition data from Eastmoney for a given stock, providing a specific resource and return type. While it doesn't explicitly differentiate from sibling stock tools, the purpose is clear enough from the Chinese title and docstring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing main business composition for a stock, but gives no explicit guidance on when to prefer this tool over alternatives or any exclusion criteria. There is no mention of alternatives.
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 already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds that the data comes from legulegu.com and returns a pandas DataFrame, but it does not disclose potential errors, pagination, data freshness, or whether the output includes historical or current constituents. This is adequate but not rich 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact: a title line, a URL, and parameter documentation. It front-loads the primary name and provides essential details without verbose explanation. The structure is a mix of natural language and code-comment style, which is slightly less readable but still economical and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the source, the input meaning, and the return type (DataFrame). However, it does not describe the structure of the returned DataFrame (e.g., columns like stock code, name, weight) or any edge cases (e.g., invalid industry code, timing of data refresh). This is a minor gap for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter description (0% coverage), but the tool description compensates by documenting ':param symbol: 三级行业的行业代码' and ':type symbol: str', clarifying that the symbol is the Level 3 industry code. The default value '801120.SI' and the URL also provide an example. This adds meaning beyond the schema, though it does not enumerate possible code formats or whether the parameter is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool provides Shenwan Level 3 industry constituents, with the name and URL pointing to an index-composition page. It specifies the resource (industry constituents) and scope (Level 3 industry), though it lacks an explicit action verb like 'get' or 'list' and does not directly contrast with sibling tools such as index_component_sw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: when you need constituents of a Shenwan Level 3 industry, provide the industry code. However, there is no explicit guidance on when to use this over alternatives, nor any exclusions or prerequisites. The description does not mention alternative tools for other Shenwan levels or different data sources.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds the data source URL and indicates a pandas.DataFrame return, but does not describe the data structure, update frequency, or any limitations. It provides some context beyond the annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the Chinese title, followed by a useful URL and return type. However, the :return: line essentially repeats the title, which is slightly redundant but not excessively wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 provides the data source and general topic, which is adequate but not complete. It does not specify the DataFrame columns, row scope, or how the data is organized, which might be needed for an agent to fully understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the schema fully covers parameter semantics. Even though the description offers no parameter details, none are needed. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific resource: AMAC's fund company and subsidiary collective asset management product disclosure, with a direct URL. The title and return line both name the exact dataset, distinguishing it from sibling tools like amac_fund_info or amac_member_sub_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/5Does 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 other AMAC tools. It only gives the dataset name and URL, leaving the agent to infer the use case. No alternatives, exclusions, or context 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?
Annotations already indicate a safe, idempotent read operation. The description adds the return type (pandas DataFrame) and source URL, but does not disclose details like pagination, data freshness, or any potential quirks. It 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, but it redundantly repeats the Chinese title from the annotations. The URL and return type lines are useful, so the structure is acceptable without being overly explanatory.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema. The description provides source, return type, and a clear label, but lacks details about the actual data columns or content that would help an agent understand what the DataFrame contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter meanings. The baseline is 4, and there is nothing requiring additional clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as AMAC futures company collective asset management product disclosure data, with a specific source URL and return type. This distinguishes it from other AMAC tools like amac_member_info or amac_fund_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/5Does 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 or any context for invocation. It only states the data source and return type, leaving the agent to infer usage from the name.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the source URL and the pandas.DataFrame return type, which is helpful but does not disclose any additional behavioral traits such as pagination, update frequency, network dependency, or potential errors. This adds some context beyond annotations but is 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, packing the source, exact disclosure type, URL, and return type into one short block. There is no fluff, but the formatting is a single dense paragraph with docstring syntax, which could be slightly more readable if broken into sentences or lines. Still, every piece of information serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and strong annotations, the description is largely complete: it names the exact data set, the source institution, and the return type. Missing details like whether the DataFrame covers all products or only current ones would be nice, but for a simple read-only lookup tool, the provided context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the input schema is empty with 100% schema description coverage. According to the rubric, a zero-parameter tool gets a baseline of 4. The description correctly notes the return type but does not need to explain parameters, so the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's scope: it returns AMAC's disclosure of securities companies' collective asset management products (证券公司集合资管产品公示). The name and URL further confirm the resource, and the specific product type distinguishes it from other AMAC tools. However, it lacks an explicit verb (e.g., 'retrieve' or 'list'), instead framing everything as a noun phrase, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the explicit product type: if an agent needs securities company collective asset management product disclosures from AMAC, this is the tool. But there is no explicit statement about when to use this versus the many other amac_* sibling tools, nor any mention of exclusions, prerequisites, or alternative 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a source URL and return type, but does not disclose additional behaviors such as whether data is historical or real-time, or any rate limits. This is acceptable given the annotations, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring-style entry with the title, source URL, parameter documentation, and return type. Every part provides necessary information with no fluff, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter data retrieval tool, the description provides a source URL, allowed symbols, and return type. However, it does not clarify whether the returned DataFrame contains historical or current yields, nor the columns included, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'symbol' property, but the description compensates by fully enumerating all 13 allowed choices (e.g., 美国10年期国债). This adds significant meaning beyond the schema, even though it doesn't explain the semantic differences between maturities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides US Treasury yield market data from Sina Finance, which identifies the resource and function. However, it does not distinguish itself from sibling tools like bond_gb_zh_sina or bond_zh_us_rate, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the data source and listing acceptable symbol values, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety traits. The description adds the data source URL and return type (DataFrame), but does not disclose additional behavioral details such as rate limits, pagination, or date range handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short, but the first line repeats the tool name as a title, and the parameter documentation is inconsistent with a typo. The structure is standard docstring format but could be more polished and error-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple data retrieval with two parameters and no output schema, so the description should provide more detail on the returned data structure. It only states '地方债发行' as the return without specifying columns, and the parameter descriptions are incomplete due to the typo.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes doc comments for both parameters, but they are identical and the end_date parameter is incorrectly described as '开始统计时间' (start time) instead of end time. The schema provides defaults implying YYYYMMDD format but no explicit description, so the description both adds and undermines clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as CNInfo's thematic statistics for local government bond issuance (地方债发行) with a return type of pandas.DataFrame. It distinguishes from sibling tools like bond_corporate_issue_cninfo and bond_treasure_issue_cninfo by focusing specifically on local government bonds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for querying CNInfo data on local government bond issuance with a date range, implying its use for historical bond issuance data. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks 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 already cover safety (readOnly, idempotent, non-destructive). The description adds the source URL and return type, but doesn't disclose data granularity or other behavioral details. The parameter choices are useful but not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear sections: overview, URL, params, return. Every line serves a purpose, and it is well-structured without superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters, and annotations cover safety. However, no output schema exists, and the description does not describe the DataFrame's columns, time frequency, or any other limitations, leaving the agent uncertain about the returned data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by listing explicit choices for both parameters (symbol: 狭义/广义乘用车; indicator: 产量/批发/零售/出口). This is essential and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (CPCA overall market statistics) and implies the action of retrieving via the `:return:` clause. The phrase '总体市场' distinguishes it from sibling car market tools, though it lacks an explicit verb like 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It only describes itself and does not mention exclusions or compare with sibling car_market_* 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and return type (DataFrame) but no deeper behavioral traits such as rate limits, pagination, or data granularity. This is adequate given the annotations, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a URL, parameter doc, return doc, and type. The first line is a noun phrase that repeats the title, but the additional elements (URL, parameter guidance) earn their place. It is not verbose and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 gives the return type and a hint for parameter discovery. It lacks details on DataFrame columns or regional scope, which could reduce usability, but given the low complexity and strong annotations, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'date' with no description (0% coverage). The description explains the date is an oil price adjustment time and points to energy_oil_hist() for valid values, adding meaning beyond the schema. However, it does not explicitly state the format (only the default implies YYYYMMDD), so it partially compensates for the lack of schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides gasoline and diesel oil prices across regions, and the :return section confirms it returns oil price for a specific date. This distinguishes its purpose (detail data for a given date) from siblings like energy_oil_hist (historical adjustment dates), though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parameter documentation explicitly instructs to call ak.energy_oil_hist() to obtain valid adjustment dates, which tells the agent how to source the required date and implicitly when to use this tool (for a specific date). It lacks explicit 'when not to use' statements but provides clear contextual guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral details like pagination ('page: -1 表示全部页面') and that empty typ means all fund types ('空串表示全部'), plus the return type. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a title, URL, and parameter list. It is longer than ideal, but each line conveys essential information given the lack of schema descriptions; the URL and title are mildly redundant with the annotation title but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, all well-explained, and a clear return type (pandas.DataFrame). With no output schema, the description adequately covers the data source and query mechanics, though it does not enumerate DataFrame columns or discuss edge cases like empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameters. It thoroughly documents all five parameters: year, typ with a complete enum list and meaning of empty string, rank with Chinese labels for each enum, sort with asc/desc choices, and page with the -1 sentinel. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '基金拆分' (fund split) from 天天基金网 and the :return: field confirms it returns a pandas DataFrame of fund split data. The query verb is implied through parameter semantics like '查询年份' and '请求第page页数据', making the purpose clear, though no imperative statement like 'Get' or 'List' is explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as fund_fh_em or fund_etf_dividend_sina. It does not state any exclusions or preferred contexts, leaving the agent to infer from the Chinese title alone.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that it returns a pandas.DataFrame of daily market data, but does not disclose any additional behavioral traits such as data source limitations, rate limits, or handling of invalid symbols. It does not contradict the annotations, but it provides minimal extra value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with a clear title, URL, and parameter definitions. Each line serves a purpose (giving choices, types, and return info). It is not overly verbose; the only potentially extraneous element is the URL, but it provides context. Overall it is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a historical data retrieval tool, the description covers the essential aspects: what data (ETF行情), from where (Eastmoney), how to specify it (symbol, period, dates, adjust), and what is returned (daily quotes DataFrame). It lacks explicit date format specification (e.g., YYYYMMDD), but the schema defaults (19700101, 20500101) and the docstring's '开始日期'/'结束日期' imply this. No output schema exists, so return details are minimal but sufficient for a simple OHLCV-type tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are no enums, so the description carries the full burden for parameter meaning. It explicitly lists each parameter with type and allowed choices: symbol as ETF代码, period as daily/weekly/monthly, start_date/end_date as dates, and adjust with qfq/hfq/'' (前复权/后复权/不复权). This is rich, necessary semantic information that the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 东方财富-ETF行情 (Eastmoney ETF quotes) with a URL, and the return type is stated as 每日行情 (daily quotes). It is specific about the data source and instrument type, though it lacks an explicit action verb like 'fetch' or 'get'. It distinguishes from siblings like fund_etf_hist_sina by the 'em' (Eastmoney) in the name and the Chinese source, but does not explicitly contrast them 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/5Does 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 such as fund_etf_hist_min_em or fund_etf_hist_sina. There is no mention of scenarios, prerequisites, or exclusions. It only states the parameters and return type, leaving the agent to infer usage from the name and parameter choices.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral details such as page=-1 meaning 'fetch all pages' and the sorting options, but does not describe potential quirks like rate limits or error handling. The added value 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a title, a source URL, parameter definitions, and return type. The long enum lists for typ and rank are necessary given the missing schema descriptions, and the content is free of fluff. It is slightly dense but earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description covers the essentials: source (URL), all parameters with meanings and defaults, and return type (pandas.DataFrame). It does not discuss edge cases or result size expectations, but for a read-only query tool with strong annotations, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving the description as the sole source of meaning. The description fully documents all five parameters, including enum choices for typ and rank, with explicit explanations for each rank value (e.g., BZDM=基金代码, DJR=权益登记日). This is exemplary compensation for an otherwise bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '天天基金网-基金数据-分红送配-基金分红' and includes the source URL, making it clear this queries fund dividend data from Eastmoney. However, it lacks an explicit verb like 'query' or 'fetch', and the distinction from closely related siblings (e.g., fund_announcement_dividend_em) is not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any exclusions or preferred use cases, leaving the agent to infer from the name and URL. This is a clear gap given the large family of fund-related 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the return type is a pandas DataFrame and includes the source URL. It does not disclose additional behavioral traits like rate limits or row count limits, but with annotations present this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with separate lines for the title, URL, parameters, and return type. The return type line repeats the title somewhat, but the overall length is appropriate for a two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only data retrieval tool with two parameters and good annotations, the description covers the essential aspects: data source, parameter provenance, allowed values, and return type. It does not list output columns or date range, but given the nature of historical NAV endpoints this is largely self-explanatory and the tool is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by explaining that code is a fund code obtained from fund_em_hk_rank() and symbol is a choice between two specific values. This adds meaningful context beyond the raw schema, though it does not specify the code format or the meaning of each symbol output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as Hong Kong fund historical NAV details and dividend/distribution details, with the data source URL. It is specific to the fund type and data type but lacks an explicit verb and does not differentiate from sibling fund history tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage hint: the code parameter should be obtained from ak.fund_em_hk_rank(), and symbol is restricted to two stated choices. However, it does not explicitly state when to use this tool instead of alternatives like fund_hk_rank_em or other historical fund tools, so the guidance is implicit.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type but does not disclose any additional behavioral traits such as data update frequency, pagination, or network dependencies. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the title, URL, return value, and return type. Every line serves a purpose with no fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides minimal context: it states the data source and that it returns a DataFrame of Hong Kong fund rankings, but does not describe the columns, ranking criteria, or whether it returns a full list. For an agent to fully utilize the output, more detail would be helpful, but the basic function is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the description does not need to explain parameter semantics. According to the baseline for 0-parameter tools, this scores 4; there is nothing missing in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Hong Kong fund rankings from East Money's data center, including the source URL and return type (pandas.DataFrame). It distinguishes from sibling tools by specifying Hong Kong funds, though it lacks an explicit action verb like 'retrieve' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the name and description: use when Hong Kong fund rankings are needed. However, there is no explicit guidance on when to use this tool versus other fund ranking tools (e.g., fund_open_fund_rank_em, fund_exchange_rank_em), and no alternatives 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data source URL and the return type (pandas.DataFrame), which is useful context. However, it does not disclose any additional traits like rate limits, pagination, or required authentication, so it adds only marginal behavioral information beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured like a docstring with title, URL, parameters, and return type. It is reasonably concise and each section serves a purpose. The URL is somewhat raw and the Chinese title duplicates the tool's subject, but overall it is well-organized and not inflated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only data retrieval tool with two parameters and no output schema, the description provides the necessary essentials: source URL, parameter choices, and return type. It does not describe the DataFrame's columns, but without an output schema that is less critical. It is adequately complete for an agent to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no enums, but the description fully compensates by listing the exact allowed values for both 'symbol' and 'indicator'. It also implicitly provides defaults via the schema. This gives the agent complete knowledge of what values are valid, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (index fund information from Eastmoney/Tiantian) and the specific data category (指数型), and the URL supports it. It lacks an explicit action verb like 'get' or 'fetch', but the intent is obvious. The tool name and description's '指数型' distinguishes it from many sibling fund info tools, though it doesn't explicitly call out those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs. other fund information tools. It does not mention exclusions or alternatives, and the sibling list contains many similar fund_info tools. The description simply states what it does without any decision context.
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 already declare readOnly/idempotent/openWorld and non-destructive, so the safety profile is covered. The description adds the current-trading-day temporal scope and pandas DataFrame return type, but discloses no further behavior such as data delay, size, or columns. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured (source, URL, return type), with no repetitive filler. The long URL and docstring are informative rather than noise, though a brief English summary would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter snapshot tool with strong annotations, the description provides enough: source, scope ('all open-end funds'), temporal window ('current trading day'), and return type. It does not enumerate returned columns, but with no output schema this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully defines invocation; the description appropriately avoids inventing parameter guidance. Baseline for zero-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('开放式基金净值' from 东方财富/天天基金) and specifies the exact returned data: all open-end fund NAV for the current trading day as a pandas DataFrame. It is distinguishable from siblings like fund_open_fund_rank_em or fund_open_fund_info_em by its daily-all scope, though it doesn't explicitly name 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a full daily snapshot of open-end fund NAVs, and the name/URL reinforce this. However, it gives no explicit guidance on when to choose this over sibling tools, no exclusions, and no mention of alternatives.
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 already declare readOnlyHint, idempotentHint, and openWorldHint, which cover the safety profile. The description adds the data source URL and return type (DataFrame) but does not disclose additional behavioral details such as pagination, rate limits, or data completeness. Given annotation coverage, the bar is met at a moderate level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the Chinese title, followed by the URL and parameter documentation. It is appropriately sized for a simple tool, though the URL is somewhat redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and strong annotations, the description is largely sufficient. However, it lacks an example call or details about the output columns, which would improve completeness; the returned DataFrame structure is only glossed as 'bond holdings'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description's param docs add meaning: symbol is 基金代码 (fund code) and date is 查询年份 (query year). This is helpful but does not go beyond basic type/meaning, leaving format details to the schema defaults (e.g., '2023', '000001').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves bond holdings (债券持仓) from Tiantian Fund Network's fund archive, with a URL confirming the source. The title and return type (pandas.DataFrame) make it specific and distinguishable from sibling fund portfolio tools like fund_portfolio_hold_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the domain-specific name and description (fund bond holdings by year), but there is no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. The sibling list includes similar portfolio tools, so more explicit direction would help.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is established. The description adds the data source URL and return type (DataFrame), which is useful but does not elaborate on pagination, rate limits, or data scope beyond 'recent'. It adds minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a title, URL, parameter documentation, and return type. It is reasonably concise, though the URL adds length and could be considered non-essential. The key information is front-loaded with the Chinese title, and the docstring format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter and no output schema, the description provides sufficient information for an agent to invoke it: the param choices, return type, and data source. It could have mentioned default behavior or data sorting, but for a simple read-only estimation tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a complete docstring listing all valid values for 'symbol' (全部, 股票型, 混合型, 债券型, 指数型, QDII, ETF联接, LOF, 场内交易基金). This significantly exceeds the input schema, which only provides type and default but no enum or explanation. The parameter semantics are fully documented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as '东方财富网-数据中心-净值估算' (East Money Net Value Estimation) and states it returns '近期净值估算数据' as a pandas DataFrame. This clearly indicates a data retrieval tool for estimated fund values, though it lacks an explicit verb like 'get' or 'fetch'. It somewhat distinguishes from siblings by its specific focus on net value estimation, but many similar fund data tools exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative fund tools, nor does it mention exclusions or prerequisites. There is no mention of alternatives or specific use cases, leaving the agent without contextual selection help.
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 already declare this as a read-only, idempotent, non-destructive operation. The description adds the recent-date constraint and the source URL, which is useful. However, it does not describe what exactly the returned DataFrame contains (columns, row count, or behavior for invalid dates), leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a structured docstring including param, type, return, and rtype. The title is repeated in the first line, which is slightly redundant, but overall it is compact and readable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter data retrieval tool with good annotations, the description covers the source, parameter constraint, and return type. It lacks specifics about the DataFrame schema and error handling, but given the tool's simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a string parameter with a default, and description coverage is 0%. The description compensates by stating the date must be a trading day and recent, narrowing down valid values. It stops short of specifying the exact format (e.g., YYYYMMDD) explicitly, but the default value implies it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a trading calendar data table from Guotai Junan Futures, which clearly indicates the resource. However, it lacks an explicit verb like 'fetch' or 'retrieve,' and the name 'futures_rule' is ambiguous until the title is read. It distinguishes from siblings by the specific calendar data scope, but not strongly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The docstring provides a key usage constraint: the date must be a trading day and recent. This guides the agent on valid input, but there is no mention of when to use this tool over other futures-data siblings, nor any exclusion criteria. It implies usage context without explicit alternatives.
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 already declare readOnlyHint=true and idempotentHint=true, so the description only needs to add context. It explains the default date behavior (current trading day) and accepted date formats, which is useful. However, it does not disclose any potential limitations, error conditions, or the exact scope of returned data beyond '结算参数数据'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the exchange name and URL, followed by clear parameter documentation. Every sentence serves a purpose, though the URL could be considered optional. The docstring style is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description provides enough information for basic usage: what it returns (pandas DataFrame), the parameter format, and default. It could be more specific about the columns or data fields, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully documents the single 'date' parameter, specifying accepted formats (YYYY-MM-DD, YYYYMMDD, datetime.date object) and the default value. This goes well beyond the schema, which only lists type 'string' and a default, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving settlement parameters from China Financial Futures Exchange (CFFEX), with a URL and resource name. It distinguishes from sibling tools by specifying the exchange in the name and title, though it lacks an explicit imperative verb like 'get' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. While sibling tools exist for other exchanges (e.g., futures_settle_czce, futures_settle_ine), the description does not mention them or provide context about when this tool is preferred.
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?
The annotations already confirm read-only, idempotent, non-destructive behavior. The description adds context by specifying the data source URL, accepted date formats, and the return type (pandas.DataFrame). However, it does not disclose potential limitations, rate limits, or error behavior. The label '展期收益率数据' seems slightly inconsistent with the basis-oriented fields, but it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with a purpose summary, source URL, parameter documentation, and a clear field dictionary. It is longer than necessary but each section adds information; the field definitions are particularly valuable given no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description's field dictionary covers return values comprehensively. Parameters are well-documented. However, it lacks explicit information about data frequency (daily vs intraday) and fails to differentiate from sibling tools like futures_spot_price_previous, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only defaults and no descriptions for start_day, end_day, and vars_list. The description compensates fully by explaining the expected formats (YYYY-MM-DD, YYYYMMDD, datetime.date), the meaning of vars_list (contract symbols like [RB, AL]), and the default behavior (all commodities). This is a strong value-add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '大宗商品现货价格及相应基差' (commodity spot prices and corresponding basis) for a specified time period. It distinguishes from likely sibling futures_spot_price_previous by focusing on a date range, though it does not explicitly compare alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter defaults (e.g., start_day/end_day default to today, vars_list defaults to all commodities) but gives no guidance on when to prefer this tool over similar options like futures_spot_price_previous or spot_price_qh. No exclusions or alternatives 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true already provided in annotations, the bar for additional disclosure is lower. The description adds the source URL (http://www.czce.com.cn/...) and the return type (dict), which gives some context. However, it does not mention behavior on invalid dates, data availability, or the structure of the returned dict. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a title line, a source URL, and a clear docstring with param/return sections. Each sentence serves a purpose, and there is no redundant or filler content. The front-loaded title immediately identifies the data domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter, and annotations provide safety info. However, there is no output schema, and the description only says the return is a dict without detailing fields or structure. It also fails to mention that the date parameter is optional with a default of '20251103' (as shown in the schema), which could affect invocation expectations. Overall, it's adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'date' parameter, so the description fully compensates. It explicitly defines 'date' as '交易日' (trading day), provides the format example '20200702', and clarifies the type as str. This is critical information for correct invocation and goes well beyond the schema's bare property definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves CZCE warehouse receipt daily data for a specified date, as shown by the title '郑州商品交易所-交易数据-仓单日报' and the return description '指定日期的仓单日报数据'. It distinguishes from siblings like futures_warehouse_receipt_dce by specifying the exchange (CZCE). However, it lacks an explicit verb like 'get' or 'list', relying on the noun phrase to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or related tools such as futures_settle_czce or futures_delivery_czce. The only contextual hint is the exchange and report name, but there is no explicit 'use when...' or 'for other exchanges use...' statement.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by specifying the return type (pandas.DataFrame) and a source URL, plus the intended downstream use of the symbol. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it repeats the return content in the first line and the ':return:' line, and includes a URL that is not essential. The structure is slightly repetitive and not tightly organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 states the output fields and type, but it does not clarify that the tool returns data for all US stocks (since there are no input params). This ambiguity about scope is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% description coverage (vacuously). The baseline for 0 params is 4; no parameter explanation is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (US stocks) and the output fields (English name, Chinese name, symbol). It distinguishes itself from sibling price-focused tools by focusing on name/symbol mapping. However, it lacks an explicit verb like 'retrieve' or 'list', relying on the tool name for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers a usage hint: 'you should use symbol to get apply into the next function', indicating the symbol's role in subsequent calls. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, so guidance is partial.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context: the data source URL, the return type (pandas.DataFrame), and a key usage hint that the 'date' parameter values should be obtained by calling ak.index_analysis_week_month_sw(). This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and uses a standard :param structure, with no redundant filler. The title is repeated in Chinese and English, which is slightly redundant, but the overall length is appropriate and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only data retrieval tool with no output schema, the description covers the source, parameters, return type, and date acquisition method. It does not enumerate return columns or discuss pagination, but these are less critical given the tool's simplicity and the safe read-only annotations. It feels complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It documents the 'symbol' choices (市场表征, 一级行业, 二级行业, 风格指数) and explains that 'date' is a query date obtained via another interface. This significantly adds value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and first line state '申万宏源研究-指数分析-月报告' (Shenwan Hongyuan Research – Index Analysis – Monthly Report), clearly identifying the resource and the monthly scope. It lacks an explicit verb like 'retrieve' or 'get', but the name implies a data-fetching operation. It distinguishes from sibling tools (daily/weekly variants) via '月报告', though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools such as index_analysis_daily_sw or index_analysis_weekly_sw, nor does it state scenarios for monthly versus daily/weekly analysis. There is 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is known to be a safe read-only operation. The description adds the source URL and parameter choices, which provide some context, but it does not disclose other behavioral traits such as data freshness, rate limits, or how the data is fetched. Since annotations carry the safety burden, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool name, followed by the source URL and a Python-style docstring. The URL adds source context but is not strictly necessary; however, it does not bloat the description. The structure is clear and efficient, though the mixed Chinese title and English docstring labels could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only index retrieval tool, the description covers the purpose, source URL, allowed parameter values, and return type (pandas.DataFrame). It does not detail the DataFrame structure (e.g., columns or date range), but given the low complexity and the presence of helpful annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines `symbol` as a string with a default, and schema description coverage is 0%. The description explicitly lists the allowed values: "周价格指数", "月价格指数", "月景气指数" (weekly price index, monthly price index, monthly prosperity index). This gives the agent complete information to invoke the tool correctly, fully compensating for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the Yiwu Small Commodity Index (义乌小商品指数) and the docstring shows it returns index results as a DataFrame. However, it lacks an explicit verb like 'get' or 'retrieve', and it does not differentiate from the many other index tools (e.g., index_ai_cx, index_si_cx) that could be confused with it. The name and URL give a clear subject, but the action is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No use cases, prerequisites, or exclusions are mentioned. The description only provides parameter choices and return type, so the agent is left to infer when this tool is appropriate.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context beyond annotations by stating the date range and the return format as a pandas Series with current value in percent, which helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The core meaning is front-loaded, but the description includes extraneous URLs and a docstring-style ':return:' block that could be cleaner. It is still concise and readable, with no redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by specifying the return type (pandas.Series) and unit (%), along with the data coverage start date. For a zero-parameter read-only tool, this is adequate, though the index or frequency of the series could be mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description correctly omits parameter details, and the baseline of 4 applies since there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a report on Japan's interest rate decisions, specifies the data range from 2008-02-14 to present, and differentiates from sibling tools focused on other countries. However, it relies on the implicit verb '报告' (report) rather than an explicit action like 'get' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 similar sibling tools such as macro_bank_usa_interest_rate or macro_japan_bank_rate. It lacks any 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that the return type is a pandas.DataFrame and includes the source URL, but it does not disclose details such as the date range, column structure, or whether the data is seasonally adjusted. For a simple read-only retrieval tool, this is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, containing the resource name, a supporting URL, and return type. However, the first line is redundant with the title (already provided in annotations), and the URL occupies a line that could have been used for more relevant behavioral details. Still, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter macro data retrieval tool, the description covers the basic purpose and return type, but it lacks detail about the DataFrame contents (e.g., columns, periodicity, units). An agent might not know whether this provides monthly or annual CPI, or if it includes multiple series. Given the lack of an output schema, the description should provide more context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain any parameters because there are none. Schema coverage is trivially 100%, and the empty schema requires no further elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool returns the Consumer Price Index for Hong Kong from Eastmoney. The specific resource (中国香港-消费者物价指数) and URL provide unambiguous scope. It also includes a return type (pandas.DataFrame), reinforcing the purpose of data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative macro indicators or sibling tools like macro_china_hk_cpi_ratio or macro_china_cpi. No context is provided about the data frequency (monthly/yearly) or specific use cases. The description only names the resource without any selection criteria.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by specifying the return type (pandas.DataFrame) and providing the source URL, which helps set expectations for the data format and origin. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four lines), but the first line exactly repeats the title provided in annotations, and the ':return:' line repeats '香港 GDP'. The URL is useful, and the docstring format with return type is clear. Slight redundancy prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only tool, the description is largely sufficient. It identifies the data, the source URL, and the return type. It does not describe the columns or time range of the returned DataFrame, but given no output schema and the simplicity of the data, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 parameters, and the schema's empty properties are sufficient. The description's mention of '香港 GDP' reinforces the output but does not add parameter-related semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (East Money) and the specific economic indicator (Hong Kong GDP), with a URL and return type. However, it lacks an explicit verb like 'retrieve' or 'list', making it more of a title than a functional description. It does not explicitly distinguish from sibling tools like macro_china_hk_gbp_ratio, though the GDP focus is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 conditions, prerequisites, or exclusions. Given the large number of sibling macro tools, this absence of usage context is a notable gap.
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 already declare read-only, idempotent, and non-destructive behavior, so the description need not repeat that. The description adds the data source URL and the return type (pandas DataFrame), providing some context beyond the annotations, but it does not detail data granularity, date ranges, or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and includes essential elements: source, indicator, and return type. It is appropriately sized, though the structure is somewhat fragmented as a title-like fragment rather than a full descriptive sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description explains the return value as a DataFrame of the HK manufacturing PPI YoY. However, it omits useful details such as the time range, frequency, or columns of the returned data, which could be important for correct interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline for this dimension is 4. The description does not need to clarify parameter semantics, and none are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Hong Kong Manufacturing PPI year-over-year data from East Money, including a specific source URL and return type. It distinguishes this tool from sibling macro indicators by naming the exact metric and region.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as other macro_china indicators. It does not mention exclusions, alternatives, or contextual use cases, leaving the agent to infer its 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds useful context by specifying the data source URL and the return type (pandas.DataFrame), but it does not disclose other behavioral traits such as data coverage, update frequency, or potential latency. With annotations doing heavy lifting, this is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a source line, URL, and return type declarations. Every element serves a purpose, and it is front-loaded with the resource name. It is appropriately sized for a no-parameter data retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, but the description provides the source and return type. However, it does not detail the exact contents of the DataFrame (e.g., columns, units, time coverage). For a simple getter, this is acceptable but leaves ambiguity about what '保险业经营情况' specifically includes, especially given the sibling macro_china_insurance_income. More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage trivially. The baseline for no parameters is 4, and the description adds no parameter information because none exist. There is no need for additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '保险业经营情况' (insurance industry operation situation) from Sina Finance's China macro data, and specifies the return type as pandas.DataFrame. It is clear what data the tool provides, but it lacks an explicit action verb and does not differentiate from the closely related sibling tool macro_china_insurance_income.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving insurance industry operating data from the Sina Finance macro dataset, but it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The context is implied by the name and description but not stated directly.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data range and return type (pandas.Series), but no additional behavioral context like update frequency or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Chinese sentence followed by two URLs and docstring-style return annotations. It is not excessively long but could be better structured; the URLs are potentially useful but add clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless data retrieval, the description is fairly complete: it gives the data range, source URLs, and return type. It does not explain the data's meaning beyond '今值', but annotations and the tool name provide sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially complete. The description adds no parameter details, but none are needed. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '欧元区制造业PMI初值报告' (Eurozone manufacturing PMI flash report) and specifies the data range, distinguishing it from other macro tools like services PMI. The return type and value are also explicit via ':return:' and ':rtype:'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is only implied by the tool name.
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?
The description adds the data range (19980501 to present), the return type (pandas.Series), and the return value semantics (今值, current value in %), which supplements the annotations' read-only/idempotent safety profile. It also provides source URLs, giving additional context about data origin. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by source URLs and return type. It is compact and easy to parse, though the URLs contribute minor noise for an agent's decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter retrieval tool with good annotations, the description provides sufficient context: the data range, the metric (current value in %), the return type, and source links. It is complete enough for an agent to invoke the tool without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input space. The description doesn't need to explain parameters; baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Eurozone unemployment rate report with a data range from 19980501 to the present, and the return line specifies the current value in percentage. It distinguishes from other region-specific unemployment rate tools via '欧元区' (Eurozone), though it doesn't explicitly elaborate on the 'mom' suffix in the description, leaving minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other macro unemployment rate tools or the numerous sibling macro_euro tools. The description only provides a data source and return type, with 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the data range and source URLs but does not disclose additional behavior such as data frequency, potential delays, or error conditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a clear front-loaded purpose followed by source URLs and return type. The two URLs are somewhat redundant but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description covers the main points: what data is returned, the date range, and return type. However, it does not fully describe the Series structure (index, frequency, columns) and there is no output schema to compensate, leaving some ambiguity about the exact return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 provides relevant context about the returned data (current values as a pandas.Series) without needing to explain parameter syntax or choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the Eurozone ZEW economic sentiment index report, with a specific date range and return type (pandas.Series of current values). It explicitly names the resource and distinguishes from the similar German ZEW tool via the 'Eurozone' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the many macro-economic siblings, nor any exclusions or alternatives. The description only states what the tool does, not when to select it.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context: it names the data source (eastmoney.com) and specifies the return type as pandas.DataFrame, which goes beyond structured annotations. However, it doesn't elaborate on data frequency (daily? historical range?) or any quirks, but given the strong annotations, this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and gets to the point, but it includes an awkwardly placed URL followed by :return: and :rtype: docstring fragments that look like leftover code documentation rather than polished prose. It is not poorly sized, but the structure is somewhat messy and could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete for a simple parameterless retrieval tool, and the annotations and empty schema make this straightforward. However, it lacks any indication of the time coverage, update frequency, or historical depth of the data, which could matter to an agent choosing between this and similar shipping index tools like macro_shipping_bci. It is adequate but with room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 with 100% coverage. The description reinforces that the tool returns the BDI index as a DataFrame, which is enough semantic context for a parameterless retrieval function. No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as returning the Baltic Dry Index (BDI) and includes a data source URL, which clearly conveys its purpose. However, it doesn't explicitly differentiate it from sibling tools like macro_shipping_bci, macro_shipping_bpi, and macro_shipping_bcti, which are related shipping indices, so it sits just below a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used for retrieving the BDI because it names the index and provides a source, but it does not explicitly state when to use it over alternatives such as macro_shipping_bci or macro_shipping_bpi, nor does it mention exclusions or complementary tools. The usage context is only implicitly that the user wants BDI data.
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?
Beyond annotations (readOnlyHint=true, idempotentHint=true), the description adds useful context: the data range from 19700101 to present, the source URL, and the return type as a pandas DataFrame. However, it does not disclose any pagination, column specifics, or rate limit behavior, which would enrich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, but it repeats '美国谘商会消费者信心指数报告' almost verbatim in the title and the return field, creating minor redundancy. It is front-loaded with the core purpose and includes a URL and return type without excessive filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description covers the essential aspects: data source, time range, and return format. It is complete enough for an AI agent to select and invoke the tool correctly, though it does not list specific DataFrame columns or any error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything. The description adds no parameter-specific details, which is acceptable and matches the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the US Conference Board Consumer Confidence Index report from Jin10 Data Center, with a specific data range. Though it lacks an explicit verb like 'get' or 'retrieve', the resource is unambiguous and distinct from sibling tools such as macro_usa_michigan_consumer_sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for retrieving the specified indicator, but does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or when not to use it. The specificity of the resource provides some contextual guidance, but 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds meaningful behavioral context: the data range, the return type (pandas.DataFrame), and that it returns the current value in percent. This is beyond what annotations provide and helps the agent understand output expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the core purpose and data range, followed by a source URL and return type. It is not overly verbose, but the inclusion of a URL and docstring-style return info slightly disrupts a clean structure. All sentences contribute relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is relatively complete. It specifies the data source, time coverage, return type, and the unit of the value. It does not enumerate DataFrame columns, but for a simple macro data retrieval that may be acceptable. The lack of alternatives or caveats is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so the baseline score is 4. The description effectively communicates what the tool returns (current PPI value in %) and its output format, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides the US Core Producer Price Index (PPI) report with a specific data range (20080318-至今). The resource and scope are explicit, and the name distinguishes it from related tools like macro_usa_ppi. However, it lacks an explicit verb like 'get' or 'return' and does not explicitly call out differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only mentions the data range, which implicitly suggests it is for historical data, but it does not mention related tools (e.g., macro_usa_ppi) or provide exclusions. An agent would need to infer usage from the tool name and context.
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 already declare read-only, non-destructive, idempotent, and open-world behavior, lowering the burden on the description. The description adds the historical data range and return type (pandas.DataFrame), which provides some behavioral context, but it does not disclose update frequency or other limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core meaning, but it contains some redundancy: the Chinese phrase repeats the tool name/title, and the docstring-style :return: and :rtype: lines add limited value. Still, it is appropriately sized with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless macro data retrieval tool, the description covers the key aspects: what data is returned (existing home sales), the date range, and the return type. The URL provides a source reference. It doesn't describe DataFrame columns, but there is no output schema, and the tool's simplicity makes the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 notes the available data range, which gives context about the dataset's coverage but not about parameter semantics (since none exist). This is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the US existing home sales annualized total report with a specific date range (19700101–present), which distinguishes it from sibling tools like macro_usa_new_home_sales. However, it lacks an explicit verb such as 'retrieve' or 'return', relying on the noun phrase and docstring to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool through its title and data range, but it provides no explicit guidance on choosing this over alternative macro indicators, nor does it mention any exclusions or related tools. Usage context is present but not elaborated.
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?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description adds useful behavioral context: it specifies the data source URL, the date range (20141006-present), that the return type is a pandas.Series, and that the reported value is the current value in percent. This goes beyond what annotations provide and helps set expectations about output format and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title-like line, a URL, and docstring-style return annotations. It avoids unnecessary prose, but the structure is somewhat informal and mixes natural language with docstring syntax. Still, every sentence earns its place, and it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema absent, the description provides essential context: the data source, date range, returned value, and return type. It does not explain the economic meaning of the index or reporting frequency, but given the simplicity of the tool and the clear name, this is adequate. The lack of an output schema makes the return description particularly valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (trivially). The description adds meaningful information about what the tool returns (current value in percent, pandas.Series) even though it does not need to explain parameters. Given the absence of parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific indicator (美联储劳动力市场状况指数报告, i.e., Federal Reserve Labor Market Conditions Index Report) and includes the data range and source URL. While it lacks an explicit verb like 'returns' or 'fetches', the :return: field clarifies that it provides the current value (今值) of the index, making the purpose understandable and distinct from other macro_usa_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions, prerequisites, or alternatives among the many macro_usa_* tools. The data range and URL imply it is for retrieving US LMCI data, but this is not explicitly stated.
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 already declare read-only, idempotent, non-destructive behavior. The description adds result limits (top 100, or all if fewer) and ratio definitions, but includes an internal inconsistency (return says top 50 while earlier says top 100), reducing clarity. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly compact but includes redundant title lines and an extraneous URL. The param/return structure is clear, but the repeated '百度地图慧眼-百度迁徙' and the 100 vs. 50 inconsistency add noise. It earns its place but could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers essential retrieval details (area, indicator, date, output type) and includes the data source URL. However, the top-100 vs top-50 ambiguity, lack of column details beyond ratios, and absence of any mention of pagination or sibling differentiation leave gaps for a data tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, acceptable values (move_in/move_out), date format and range, and the requirement for full area names. This is strong parameter-level guidance beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Baidu Migration area details (incoming/outgoing) for a specified area, indicator, and date, and it explains the proportion metrics. However, it does not explicitly differentiate from sibling tools like migration_scale_baidu, relying on the title and parameter docs to convey the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage constraints (full-name requirement for area, valid date range, indicator values) but does not state when to use this tool versus alternatives. No explicit exclusions or references to sibling tools are given, so the agent must infer suitable use from context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only behavior is covered. The description adds that the date parameter refers to the 'complete week before the current date' and that the return is a pandas.DataFrame, which is useful context beyond the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing a title, source URL, parameter docstring, and return type in four lines. It avoids redundancy for the most part, though the return line ('影票房-影院票房-轴票房排行') contains a typo and repeats the title. Overall, it is appropriately sized and front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify the returned DataFrame structure; it only states 'pandas.DataFrame' without column details. The date semantics are also vague, potentially causing misuse. While the annotations cover safety, the description lacks sufficient detail about output and precise date interpretation to be considered fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must compensate. It provides a brief explanation of the date parameter: '当前日期前完整一周的票房数据' (box office data for the complete week before the current date). While this clarifies the date's role, it is ambiguous about whether the date is the end date or the start of the week, and it does not specify the format beyond the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '电影票房-影院票房-周票房排行' (Movie box office - Cinema box office - Weekly ranking), naming the specific resource (cinema weekly box office) and the intended data (rankings). It distinguishes from sibling tools like movie_boxoffice_cinema_daily (daily) and movie_boxoffice_weekly (likely overall, not by cinema) by including both 'cinema' and 'weekly'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for weekly cinema box office rankings but does not explicitly state when to use this tool versus alternatives. It provides no exclusions or references to alternative tools. The date parameter description gives some context on how to set the date, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: it documents the date limitation (only previous day's data) and the return type (pandas.DataFrame), which are not evident from the schema or annotations. It also provides the source URL, adding transparency about the data origin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and follows a clear structure: title, URL, parameter documentation, and return documentation. Every section earns its place, but the opening line repeats the title exactly, and the parameter/return sections are minimal. It is appropriately sized for a simple tool, though not excessively polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 safe annotations, and the description provides the source URL, date limitation, and return type. However, there is no output schema and the description only says '每日票房' (daily box office) without detailing what columns or aggregated data the DataFrame contains. This leaves the agent guessing about the exact return structure, so the description is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type with no description (0% coverage). The description compensates somewhat by stating the date constraint ('只能设置当前日期的前一天') and the type as str, but the type is already in the schema and redundant. It does not explicitly specify the expected date format (e.g., YYYYMMDD), although the default value '20240219' hints at it. Thus it adds meaningful but incomplete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as daily movie box office data (电影票房-单日票房) and returns a DataFrame of daily box office. However, it uses a noun phrase rather than a specific verb like 'retrieve' or 'get', and it does not explicitly differentiate from sibling tools such as movie_boxoffice_monthly or movie_boxoffice_realtime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a crucial usage constraint: '只能设置当前日期的前一天的票房数据' (dates are limited to the day before the current date), which tells the agent when the tool can be used. However, it lacks explicit guidance on when to choose this tool over the movie_boxoffice_* siblings, nor does it mention alternatives. The usage context is implied by the name and title rather than stated directly.
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?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds meaningful context by specifying the valid date range and the return type (pandas.DataFrame), but it does not disclose error handling, rate limits, or pagination, which could be relevant for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a docstring-like structure with source, parameter, and return sections. Every line provides useful information without unnecessary fluff, though it could be marginally better organized with clear field labels.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single optional parameter and no output schema, the description covers the essential aspects: what it does, the source URL, parameter semantics, and return type. It omits minor details like optionality and behavior on invalid dates, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining the `date` parameter's meaning and valid range. It clearly states the data is retrieved for a given date and only available after 2016-02-03, though it does not explicitly spell out the expected date format (YYYYMMDD), which is inferred from the default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the CCTV News Simulcast (新闻联播) transcript and includes the source URL, making its intent obvious. However, it lacks an explicit verb such as 'fetch' or 'get', so it falls short of being a fully specific verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates a key usage constraint (data available only after 2016-02-03) and implies that the user should supply a date. It does not, however, provide any guidance on when to prefer this tool over sibling news-related tools or how to handle invalid or out-of-range dates.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and the return type (list of contract expiry times), but does not disclose additional behavioral traits such as rate limits, authentication needs, or the format of the list entries. It neither contradicts annotations nor provides rich 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear title, URL, parameter list, and return type. However, the title in the description duplicates the annotation title, and the 'exchange: null' line adds no value. These minor redundancies prevent a perfect score, but the structure is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is mostly sufficient. It states the purpose, parameters, and return type. However, it lacks clarity on the 'exchange' parameter (which is confusingly described as 'null') and does not specify the exact format of the returned expiry month list. Given the tool's low complexity, it is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It does provide meaningful guidance for the 'symbol' parameter by stating it accepts '50ETF' or '300ETF'. However, the 'exchange' parameter is described as 'null', which is unhelpful and does not clarify its purpose or valid values. The return type is also mentioned, adding some value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it lists contract expiry months for SSE 50ETF/300ETF options from Sina Finance. The Chinese title '新浪财经-期权-上交所-50ETF-合约到期月份列表' is specific and unambiguous, and the return type is explicitly defined as a list of expiry times. It distinguishes from sibling option tools (e.g., daily, minute, spot price tools) by focusing on '到期月份' (expiry months).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a list of contract expiry months is needed. However, it does not explicitly state when not to use it or provide alternative tool recommendations. For example, there is no guidance distinguishing it from option_sse_expire_day_sina, which lists expiry days. The usage context is clear but not explicit.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable context: data is real-time and historical queries are unsupported, plus it illustrates the output schema with a concrete example. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the title and key constraints, but the extensive example table with many rows makes it longer than necessary. A compact column description would suffice, though the sample data does help visualize the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description provides the return type, example data, and a key constraint (real-time only, no history). This is adequate for basic usage, though it lacks error handling or details about the URL parameter's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one optional url parameter with a default but no description. The description includes ':param url: str 网址,' clarifying it's a URL string, but offers no further detail about acceptable values or when to override the default. Since schema description coverage is 0%, the description partially compensates but remains minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a '外盘比价' (foreign market price comparison) as a pandas DataFrame, with a sample showing columns and data. It also notes real-time data and no historical query capability, distinguishing it from historical data tools, though it doesn't 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool provides real-time data and cannot query historical data, offering context on when it's appropriate. However, it doesn't provide explicit alternatives or when-not-to-use guidance beyond the historical data limitation.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the return type (pandas.DataFrame) and the URL as data source, but does not disclose behaviors like update frequency, timezone, or missing data handling. It does specify the time period ('今年以来') which is useful, but not 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a title line, a URL, and a docstring-style return type. It is front-loaded with the main meaning, but the title line and the :return: line repeat the same phrase '今年以来全国出栏均价走势', creating slight redundancy. Still, it is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple no-parameter tool with annotations covering safety, but there is no output schema. The description tells the agent it returns a DataFrame of the national average price trend since the start of the year, but lacks details such as frequency (daily/monthly), units, or column names. It is adequate for a basic data fetch but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters and the schema coverage is 100%, so under the rubric the baseline is 4. The description reinforces that no inputs are needed and clarifies the output is a DataFrame of the year's trend, which adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the national slaughter average price trend since the beginning of the year from Soozhu's pig big-data platform. It specifies the exact resource (全国出栏均价走势) and the source URL, distinguishing it from sibling soozhu tools that provide spot prices or other hog-related metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or compare to sibling tools such as spot_hog_soozhu or index_hog_spot_price. Usage is only implied by the data description, not stated.
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 already declare readOnlyHint=true and destructiveHint=false. The description adds the return type (pandas.DataFrame) and the source URL, but does not disclose data frequency, time range, columns, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and structured with a title, URL, and docstring return type. The first line repeats the title annotation, which is slightly redundant but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool, the description provides the essential purpose and return type, but lacks detail on the output columns or the exact meaning of '走势' (trend), which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The schema is empty and the description correctly makes no parameter claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns '全国豆粕价格走势' (national soybean meal price trend) from the soozhu data center, and specifies the return type as pandas.DataFrame. The name and description distinguish it from sibling tools like spot_corn_price_soozhu by commodity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 whether to use it for historical analysis, real-time spot prices, or how it compares to related hog/feed price tools.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds value by specifying the source URL and the pandas.DataFrame return type, clarifying that the full industry overview list is returned. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at four lines and front-loads the source and resource. The first line redundantly repeats the title annotation, which costs a small amount of efficiency, but the URL and return-type lines earn their place. Overall well-sized with no filler beyond the title duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only summary tool with rich annotations, the description provides adequate context: the data source (THS data center), the exact URL, and the return type. The main gap is not enumerating the columns or contents of the overview table, but '一览表' (overview list) plus the sibling context makes the output scope reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain about inputs. Baseline of 4 applies, and the description appropriately focuses on the output instead of inventing parameter details. No parameter ambiguities exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the THS industry overview table (同花顺行业一览表) from the THS data center, with an explicit :return: and :rtype: indicating a pandas DataFrame result. While the verb is implied rather than stated, the Chinese title and URL clearly convey a fetch/list operation. It does not explicitly differentiate from sibling industry-board tools like stock_board_industry_spot_em or stock_board_industry_name_ths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Given many siblings cover industry boards (stock_board_industry_spot_em, stock_board_industry_index_ths, stock_board_concept_summary_ths, etc.), the description offers no contextual hint, exclusions, or alternative recommendations. The usage context is only implicitly inferable from the name and title.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the quarterly granularity constraint and indicates the return type (DataFrame), which provides some behavioral context. However, it does not disclose data source caveats, update frequency, or any limitations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, organized as a mini-docstring with sections for URL, param, return, and rtype. Every line contributes useful information, though the URL could be seen as redundant given the tool's behavior is already clear. It is appropriately front-loaded with the tool name and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a single parameter and no output schema, the description covers the essential aspects: what data is returned (cash flow statement), the period granularity (quarterly), the input requirement (symbol with market prefix), and the return type. It lacks details like whether it covers all historical quarters or any rate limits, but given the annotations and simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. The docstring explains ':param symbol: 股票代码; 带市场标识' (stock code with market identifier), which clarifies the expected format (e.g., SH600519) beyond the schema's bare type string. It also aligns with the default value in the schema. More examples or case sensitivity would help, but it is sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('现金流量表' = cash flow statement) and the scope ('按单季度' = by single quarter), which distinguishes it from siblings like 'stock_cash_flow_sheet_by_yearly_em'. However, it lacks an explicit action verb, relying on the noun phrase structure to imply 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the '按单季度' (by single quarter) label, which differentiates it from yearly or report-period tools. But it provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites. The URL offers a source reference but no practical usage context.
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 already mark this as read-only, idempotent, and non-destructive. The description adds the source URL (Sina Finance) and the return type (pandas.DataFrame), but does not disclose data freshness, pagination, or column details. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with a short purpose line, source URL, and docstring. It is well-structured for a simple tool, though the initial line is a fragment rather than a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of safety annotations, the description covers the essential invocation details (valid parameters) and the return type. It doesn't include an output schema, but none is provided; it's adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for symbol, but the docstring compensates by listing valid categorical values and the default. This is essential for correct invocation, so the description adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns stocks classified by a specified classification system (Shenwan industry, second-level, hot concepts, regional sectors). It clearly names the resource and options, distinguishing it from broader stock list tools, but the verb 'list/retrieve' is implicit and the phrase '按 symbol 分类后的股票' is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates the four valid symbol values, giving the agent a clear sense of when this tool is applicable (e.g., when needing Shenwan industry constituents). However, it does not explicitly state when to prefer it over alternatives like stock_sector_spot or stock_board_concept_spot.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), but does not disclose other behavioral traits such as rate limits, pagination, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and organized as a docstring: purpose stated first, then URL and parameter documentation. Every element is useful, though the URL is additional context rather than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only data retrieval, the description provides sufficient information: data source, dataset name, allowed parameter values, and return type. The lack of column details in the returned DataFrame is a minor gap since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'symbol' parameter, but the description explicitly lists the four allowed values ('近一月', '近三月', '近六月', '近一年') and its type (str). This fully compensates for the schema's 0% coverage and is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (东方财富网-数据中心-大宗交易) and the specific dataset (活跃 A 股统计), and mentions the return type (DataFrame). However, it lacks an explicit verb like 'fetch' or 'get' and does not differentiate itself from sibling block-trade statistics tools such as stock_dzjy_mrmx or stock_dzjy_sctj.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling block-trade tools. There are no stated prerequisites, conditions, or exclusions, leaving the agent to infer usage solely from the dataset name.
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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is clear. Description adds the data source (THS) and the financial statement type (balance sheet), and includes a URL for reference. It doesn't describe rate limits or return format details, but the annotations cover the key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the title. The use of a URL and docstring-style parameters is efficient, though the URL takes up space and could be considered noise. Still, it's short and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool with 2 optional params and read-only annotations, the description covers the essential: source, type of data, and parameter meaning. No output schema exists, but the return type is stated as pandas.DataFrame. The tool is relatively simple compared to others, and the description is adequate for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists two parameters: symbol (stock code) and indicator (choice of 按报告期 or 按年度). This adds meaning: symbol is a stock code, indicator is a choice between 'by report period' and 'by year'. However, it doesn't provide examples or defaults beyond the schema's default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for THS (同花顺) financial debt/balance sheet data. The title also confirms it's about the balance sheet. It uses a specific verb and resource, and the URL helps identify the data source, though it doesn't explicitly differentiate from siblings like stock_zcfz_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: it's a data retrieval tool for balance sheet data from THS. The description's URL and title suggest when to use it, but there's no explicit guidance on when to use this vs alternatives like stock_zcfz_em (balance sheet from EM) or stock_financial_debt_ths. Sibling tools exist but no differentiation is 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety expectations. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose additional behaviors like rate limits, data granularity, or the meaning of the ranking periods beyond the literal values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear title, source URL, parameter documentation, and return type. It avoids unnecessary prose but is slightly dense due to the docstring format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 source, valid inputs, and return type, which is sufficient for basic usage. It lacks detail on output columns or the precise meaning of each ranking period, but these are not essential giventhe simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is minimal (type string, default '即时'), but the description provides the full enumerated choices: {'即时', '3日排行', '5日排行', '10日排行', '20日排行'}. This is critical for correct invocation and far exceeds the schema's information. The return type is also clearly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific data resource (同花顺-数据中心-资金流向-行业资金流) and URL, making clear it provides industry-level fund flow data. It distinguishes from siblings like stock_fund_flow_concept or stock_fund_flow_individual by specifying '行业' (industry). However, it lacks an explicit verb like 'fetch' or 'list', relying on implication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_sector_fund_flow_rank or stock_sector_fund_flow_summary. The description only states what the tool is without contextual usage advice.
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 already declare the tool as read-only, non-destructive, and idempotent, so the description's addition of a pandas.DataFrame return type and explicit parameter choices adds some context. It does not disclose data granularity, row/column semantics, or any behavior beyond 'returns top 10 shareholders'. Given the strong annotations, the description adds modest behavioral context, but not enough to fully characterize the tool's output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the dataset name and source URL, followed by concise parameter and return documentation. Every line carries distinct value—title identifies the data, URL provides provenance, param docs clarify the only input, and return type sets expectations. No redundant phrases or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and rich annotations, the basic inputs and safety profile are covered. However, there is no output schema, and the description merely states '十大股东' without specifying columns, row meaning, or the semantics of '协同' (collaboration). The tool could plausibly return data for a specific stock vs. a market-wide view, which is not clarified. The description is adequate for a simple tool but leaves the agent uncertain about result structure and exact usage scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'symbol' parameter, and the parameter name is ambiguous (it actually represents shareholder category, not a ticker). The description fully compensates by listing all allowed values ('全部', '个人', '基金', 'QFII', '社保', '券商', '信托'), giving clear semantic meaning to an otherwise opaque parameter. This exceeds the baseline requirement for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific data source and dataset ('东方财富网-数据中心-股东分析-股东协同-十大股东') and states the return type ('十大股东' DataFrame). It clearly differentiates itself from sibling tools by naming the '股东协同' (shareholder collaboration) section, which is distinct from other holding/change/detail variants. However, it lacks an explicit verb like 'retrieves' or 'lists', relying on the 'return' line to imply the retrieval action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 stock_gdfx_holding_analyse_em or stock_gdfx_free_holding_teamwork_em. It only lists parameter choices and return type, with no mention of use cases, exclusions, or synonyms. The name 'teamwork' implies a specific use case, but the description fails to articulate it, leaving the agent without decision support.
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 already declare this is read-only, idempotent, and non-destructive. The description adds the return type (pandas.DataFrame) and source URL, but does not reveal additional behavioral traits such as data freshness, pagination, or network dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and well-structured, front-loading the title and including useful metadata (URL and return type). It loses a point for repeating '质押机构分布统计-证券公司' twice, which is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter, read-only tool, the description provides sufficient context: it states the source, the specific data topic, and the return type. While it lacks column details or examples, the annotations and simplicity of the tool make this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. The description does not need to add parameter details; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: pledge institution distribution statistics for securities companies, with an explicit source URL. It distinguishes from sibling tools like the bank variant by specifying '证券公司' (securities companies), though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage through the specific dataset name and URL, making it clear this is for securities company pledge distribution stats. However, it provides no explicit when-to-use guidance or comparisons to alternative tools in the same family.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the data source (eniu.com) and return type (pandas.DataFrame), but does not disclose any potential quirks like data availability or rate limits. With annotations present, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with a title, URL example, and docstring-like param/return sections. The URL example is slightly redundant but not wasteful. It gets to the point without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose, parameters, and return type, but lacks details on the DataFrame structure (columns), the meaning of the '港股' indicator option, and any limitations. For a two-parameter tool with no output schema, it is minimally sufficient but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and defaults with 0% description coverage, but the description compensates by defining symbol as 港股代码 and listing the exact allowed values for indicator. This adds significant meaning beyond the structured schema, making the parameters understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches HK stock indicators from eniu.com, listing specific indicators (市盈率, 市净率, etc.). This directly distinguishes it from sibling tools like stock_hk_daily or stock_hk_spot, which focus on price data. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not specify scenarios (e.g., when needing valuation ratios vs. price history) or mention exclusions. The only usage hint is the indicator choice list, but no contextual direction is given.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful detail about the symbol format (market representation) and return type, but discloses no unexpected behaviors, side effects, or limitations beyond what one would assume from a read-only data retrieval 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a structured docstring format with separate sections for source URL, parameter, and return. Every line contributes essential information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 there is no output schema, so the description carries the burden of explaining return values. It states the return type is pandas.DataFrame and that it contains related stocks, but it does not detail the columns, data semantics, or any possible variations in the response. Given the missing output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter with no description (0% coverage), so the description must compensate. The docstring clearly explains that 'symbol' should be a security code with market representation (e.g., 'SZ000665'), which adds meaning beyond the raw parameter name and default value. It could provide a more detailed format specification, but it is sufficient for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'related stocks' from the East Money individual stock popularity list, which distinguishes it from siblings like stock_hot_rank_em. However, it lacks an explicit verb such as 'retrieve' or 'get', making it a noun phrase rather than a full functional statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its title and parameter definition (given a symbol, get related stocks), but it does not explicitly mention when to use this tool versus alternatives or provide exclusions. The URL example provides minimal context but no comparative guidance.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and parameter details, but nothing about pagination, rate limits, or data scope beyond that. With strong annotation coverage, this is acceptable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with clear sections (:param:, :type:, :return:, :rtype:). It includes a source URL for context and is appropriately sized for a simple one-parameter tool. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description covers the essential aspects: data source, parameter choices, return type, and URL. It assumes domain knowledge about Stock Connect but is adequate for a simple historical data fetcher. Minor gaps include lack of date range or data granularity, but that's acceptable for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'symbol' with no description and no enum. The description fully compensates by listing all accepted choices (北向资金, 沪股通, etc.) and the type (str). This is essential for correct invocation and adds complete meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 沪深港通历史数据 (Stock Connect historical data) from East Money, with the title and parameter choices making the resource explicit. However, it does not explicitly use a verb like 'retrieve' or 'fetch', and while the 'hist' in the name distinguishes it from other HSGT tools, the description itself doesn't directly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus other HSGT-related tools like stock_hsgt_fund_flow_summary_em or stock_hsgt_fund_min_em. It only lists the symbol choices, implying usage for historical data but lacking explicit 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it returns a pandas DataFrame and specifies the return type, but does not disclose additional behavioral traits such as data freshness, pagination, or rate limits. Some value added 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, containing a source label, URL, parameter documentation, and return type in a standard docstring format. It is efficient without wasted words, though it mixes Chinese and English but remains readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description provides the source URL, parameter choices, and return type, which is adequate. However, it could improve by explicitly stating that it covers individual stock fund flow rankings and distinguishing it from sector/industry fund flow rank tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lacks any description for the 'indicator' parameter and no enums are defined. The description compensates by listing the valid choices and indicating that they are period options, thereby providing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the resource (East Money data center fund flow ranking) and the action (return ranking), though it lacks an explicit imperative verb. It is distinct from siblings by implying rank-focused fund flow data, but does not explicitly state 'individual stock' 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by listing indicator choices ('今日', '3日', '5日', '10日') and the data source URL, implying when to use it. However, it does not explicitly state alternatives or when not to use this tool, leaving usage guidance implicit.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and the source URL (https://www.szse.cn/...), which is useful context, but does not detail other behavioral aspects such as data coverage, pagination, or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter definition, and return type, all in a standard structured format. Each line serves a purpose, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool, the description adequately covers the essentials: the source, the parameter choices, and the return type (pandas.DataFrame). It lacks examples or details about the DataFrame columns, but given the low complexity and the presence of annotations, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows a default value ('终止上市公司') with no description. The description explicitly enumerates the two allowed values for symbol ('暂停上市公司' and '终止上市公司') and specifies the type as str, providing essential semantic information that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing data on suspended and terminated listed companies from the Shenzhen Stock Exchange (SZSE) by specifying the two categories and including the source URL. The return statement 'return: 暂停上市公司 or 终止上市公司 的数据' makes the purpose explicit, though it lacks a strong imperative verb like 'Get' or 'List'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the two valid values for the symbol parameter, which guides the user on what data each option returns. However, it does not explicitly state when to use this tool versus sibling tools (e.g., stock_info_sh_delist) or provide any contextual guidance on when this tool is appropriate.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context: it specifies the return type (pandas.DataFrame) and the data source (Sina Finance). It does not mention error behavior, rate limits, or data coverage limitations, so moderate transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a title/URL line, then parameter and return documentation. The detailed quarter format explanation is essential and presented efficiently with examples. The URL adds some redundancy but does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter semantics fully, specifies the return type, and mentions the data source. Rich annotations handle safety aspects. Although there is no output schema, the return-type description is adequate for an agent to know what to expect. Specific DataFrame columns are not described, but this is not critical for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates. It thoroughly explains the 'quarter' parameter: the mapping from report types (一季报=1, 中报=2, 三季报=3, 年报=4), the starting year (2005), and concrete examples ('20191', '20193'). The 'stock' parameter is defined as '股票代码' (stock code), providing clear meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns institutional holding data for a specified stock and financial reporting quarter, with 'return' explicitly documented. The resource and scope are specific (Sina Finance institutional holdings detail), but it does not explicitly contrast with sibling tools like stock_institute_hold, relying on the 'detail' suffix in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed formatting guidance for the 'quarter' parameter, including valid values and examples, which aids correct invocation. However, it offers no guidance on when to use this tool versus alternatives such as stock_institute_hold or other holding-related functions, and no exclusions or alternative suggestions are given.
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 already declare readOnlyHint=true and destructiveHint=false, and the description adds that it returns a pandas DataFrame. The description does not disclose any additional behavioral traits such as data freshness, source pagination, or any quirks about the returned data. Since the annotations cover the safety profile, the description adds some value (return type, source) but not deeply rich 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the source and purpose, followed by the URL and return type. It is efficient without unnecessary fluff, but could be slightly better structured by including a brief note on the returned data fields or update frequency. However, it's still appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and annotations already indicate it is a read-only, idempotent operation, the description is sufficient for an agent to select and invoke it. It lacks details about the exact columns of the returned DataFrame, but the URL and title give enough context. The complexity is low, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema provides all necessary information. The description does not need to explain any parameter semantics. The description does imply the tool returns all real-time quotes for the board without filtering, which is useful for understanding the scope of the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that this tool retrieves real-time quotes for the 科创板 (STAR Market) from Eastmoney, but it is somewhat unclear whether 'spot' means the full list of all KCB stocks or a snapshot quote. The URL and return type clarify the data source, but the description does not explicitly distinguish this from other stock_*_spot_em siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is for real-time market data from the 科创板 board, which is clear from the title and URL. However, it does not explicitly state when to use this tool over alternatives like stock_cy_a_spot_em or stock_zh_a_spot_em, nor does it mention any exclusions or prerequisites. The context implies it is for 科创板 spot quotes, but no explicit guidance is provided.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds an important behavioral detail beyond annotations: the result may be limited to the top 5 shareholders for specific stocks/timepoints. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear docstring structure (param/type/return/rtype). It has some redundancy by repeating the tool title at both the beginning and the return section, but the URL and P.S. note are useful and not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description covers the core purpose and a key limitation. However, without an output schema, it only states that a pandas DataFrame is returned without specifying columns or expected contents, which is a gap for an agent to understand the result fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'stock' parameter, so the description's ':param stock: 股票代码' and ':type stock: str' provide necessary context that it is a stock code. The URL and examples give format hints, but the description does not explain required vs optional or discuss edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving Sina Finance's major shareholders data (新浪财经-股本股东-主要股东) for a given stock, with a supporting URL and return type. It conveys the resource and scope, though it lacks an explicit action verb and does not differentiate from similar shareholder-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The P.S. note provides a usage caveat (only top 5 shareholders for certain stocks at certain times) and an example stock code (000002), implying when it is appropriate to use. However, it does not explicitly state when to use this tool over other shareholder-focused tools or 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context: the data source (Eastmoney), the default behavior of returning all data, and the ability to filter by industry sector. It does not mention pagination, update frequency, or rate limits, but the simple read-only nature keeps this acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and combines source, URL, parameter documentation, and return type in a small docstring. There is no filler or redundant text. It could be slightly more front-loaded with an explicit action statement, but it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and strong annotations, the description covers the essential aspects: source, filter semantics, and return type as a pandas DataFrame. It does not list output columns or clarify how it differs from similar profit-forecast tools, but those are secondary for this simple read-only endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for the single 'symbol' parameter. It fully explains that an empty string ('') returns all data, a specific sector name like '船舶制造' filters by industry board, and that valid board names can be retrieved via ak.stock_board_industry_name_em(). This is comprehensive and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as Eastmoney's profit forecast (盈利预测) data from the research report center and lists the source URL. It implies retrieval via the docstring's ':return: 盈利预测' and 'pandas.DataFrame', but lacks an explicit verb such as '获取/查询'. The source name '东方财富网' helps distinguish it from similar sibling tools like stock_profit_forecast_ths, though it does not explicitly contrast 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/5Does 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 such as stock_profit_forecast_ths or stock_research_report_em. It only explains the symbol parameter behavior (empty means all data, a sector name filters by industry), which is parameter usage rather than tool-selection guidance.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description does not need to cover safety. It adds useful context about sector choices and the excluded sector, but does not describe pagination, rate limits, or the full return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with a title, source URL, parameter documentation, and return type. No unnecessary words; it is front-loaded with the purpose. The docstring format is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 what '板块详情' concretely contains (e.g., constituent stock codes/names/prices). It only provides a broad phrase and a URL, leaving the agent to infer the DataFrame columns. This is a notable gap for a data-returning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter, but the description compensates by explaining that sector is the label from stock_sector_spot, listing the valid choices, and noting an excluded value. However, the schema default 'gn_gfgn' is not among the listed choices, creating potential confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns details for a specified sector, and the title/name ('成份详情', component details) imply constituent-level data. It distinguishes itself from stock_sector_spot (which lists sectors) but does not explicitly name the difference or state the exact output content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs the agent to obtain the sector label from stock_sector_spot, lists the valid choices for sector, and notes that '启明星行业' has no details. This gives clear when-to-use guidance, though it doesn't compare with other detail tools.
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?
The description adds key behavioral context beyond annotations, including the 15-minute data delay, which is critical for time-sensitive decisions. It also specifies the source URL and return type (pandas DataFrame). Annotations already cover read-only and idempotency, so the extra details are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by the source URL and return type. Every line adds value (source, delay, return type) with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool returning a snapshot, the essential details are covered: data source, universe (all US stocks), delay, and return type. The empty schema and simple behavior make the description complete, though it could mention columns or data volume without harming the overall adequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing to describe. The baseline for 0 params is 4, and the description doesn't need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides '所有美股的数据' (all US stock data) from Sina Finance, with a return of real-time quotes. It distinguishes itself from siblings like `stock_us_spot_em` by specifying the source (Sina) and universe (all US stocks), though it lacks an explicit action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 15-minute delay is a caution but not a usage recommendation, and there is no mention of when to prefer other spot tools or what to use for lower latency or different data.
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 already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds that it returns a pandas DataFrame and points to a data source URL, but does not disclose potential errors, rate limits, or data quirks. This adds some context beyond annotations but not substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear structure: title, source URL, parameter definitions, and return type. It is not overly verbose, but the URL and type info are arguably necessary. It front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema), the description covers purpose, parameters, and return type. It does not detail column names or edge cases, but annotations cover safety and idempotency. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters, but the description compensates by enumerating valid values for 'symbol' and providing example date formats and a start date. This gives the agent clear semantics for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves scheduled disclosure times from East Money's data center, with a specific URL and return type. However, it does not explicitly differentiate it from sibling tools like stock_yjbb_em or stock_yjkb_em, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter documentation but does not state when to choose this tool over alternatives, nor does it offer any context on use cases or exclusions. It only describes what the tool does, not when to use it.
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?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds a valuable behavioral warning that large-scale scraping may lead to IP bans, and also specifies the return type as pandas.DataFrame. This provides context about rate limits and output format not present in the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear front-loading of the tool's purpose and resource URL. The parameter docs are structured and useful, though the style is a bit docstring-like with some redundancy (e.g., repeated type information).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a historical data retrieval tool and the rich annotations, the description adequately explains the data source, parameters, and return type. It lacks details about output columns or data adjustments, but with no output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by documenting each parameter (start_date, end_date, symbol) with example values and Python types. This gives the agent meaningful context for constructing valid inputs, although it doesn't explicitly define date format constraints beyond examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Sina Finance A-share CDR individual stock historical market data, with a source URL. This distinguishes it from sibling stock history tools by its specific CDR focus, though it lacks an explicit verb like 'fetch' or 'query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool vs alternatives. It only includes a caution about IP bans from heavy scraping, which is a warning rather than usage direction. The CDR-specific scope is implied by the name and description, but 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds context beyond annotations by naming the source URL, specifying the return type (pandas.DataFrame), and explaining the parameter format, but it doesn't disclose additional behavioral traits like rate limits, data freshness, or error conditions. With such rich annotations, this is adequate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured docstring that front-loads the source/title, then uses :param: and :return: tags. It avoids unnecessary prose; the URL and format note are useful. It is slightly cryptic due to the Chinese language and mixed docstring format, but each element earns its place—just not quite a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 parameter and no output schema. The description covers source, data content, parameter values/format, and return type. It doesn't describe the DataFrame columns, but the name '股东户数' and source make the content clear. For a simple query tool with rich annotations, this is sufficiently complete, though stating it returns all A-shares (rather than a single stock) would make it fully explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a string type with a default value and no description. The description compensates fully by explaining that symbol accepts either '最新' or a quarter-end date formatted as YYYYMMDD (e.g., 20230930), which is crucial for the agent to pass the correct value. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (东方财富网/数据中心的特色数据) and the dataset (股东户数/shareholder counts), and the :return:/:rtype: fields specify it returns a pandas DataFrame. However, it lacks an explicit verb like 'fetch' or 'retrieve', and doesn't differentiate itself from closely related siblings such as stock_zh_a_gdhs_detail_em, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The :param symbol: description explains the two allowed values ('最新' and '每个季度末' with YYYYMMDD format), which is helpful for correct invocation. However, there is no guidance on when to choose this tool over sibling tools (e.g., when to use stock_zh_a_gdhs_detail_em for more granular data), so the 'when vs alternatives' aspect is missing.
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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds return content but introduces an internal contradiction: :return: says '字典' (dict) while :rtype: states pandas.DataFrame, and it does not clarify the actual structure or columns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, containing a title, source URL, and return docs in a few lines. However, the return-type inconsistency and lack of clean organization prevent it from being exceptionally well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description conveys the essential purpose and return shape, but the dict/DataFrame conflict and absence of details about key/value structure leave ambiguity. No output schema exists, so the description must carry the full burden, which it only partially meets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already captures everything needed. With no parameters, the baseline of 4 applies, as the description is not required to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a dictionary of stock codes and names for Tencent Finance HK AH stocks, supported by a source URL. The title and return description distinctly identify it as a name lookup tool, differentiating it from siblings like stock_zh_ah_daily and stock_zh_ah_spot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing the AH stock name mapping via its :return: statement, but provides no explicit guidance on when to choose this tool over alternatives or any exclusions. No alternative tools are mentioned, leaving context implied rather than stated.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with these—no contradiction. The description adds useful context by specifying the return type (pandas.DataFrame) and the 'real-time' nature of the data, while omitting details like rate limits, refresh behavior, or column-structure caveats. With strong annotations covering the safety profile, the marginal behavioral disclosure 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact four-part docstring (title, source URL, param doc, return doc) with no wasted words. The URL provides provenance, and the param/return sections are essential. The structure is standard and well-understood, though it could theoretically drop the URL without losing core semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description covers the key aspects: data source, market scope, all parameter choices, and return type as a DataFrame. It omits DataFrame column details and data-freshness specifics, but for a snapshot-style quote tool backed by strong safety annotations, the coverage is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It compensates excellently by enumerating all five allowed values for 'symbol' ('沪深重要指数', '上证系列指数', '深证系列指数', '指数成份', '中证系列指数'), specifying the default ('上证系列指数'), and documenting the type (str). This adds substantial meaning beyond the bare schema, which only shows a string type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches real-time spot quotes for Shanghai/Shenzhen/Beijing indices from East Money ('东方财富网-行情中心-沪深京指数' and ':return: 指数的实时行情数据'). The URL and '沪深京' scope help distinguish it from HK/global index siblings (e.g., stock_hk_index_spot_em, index_global_spot_em), and the '_em' suffix plus URL identify the East Money source. However, the differentiation is implicit rather than explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Among siblings like stock_zh_index_spot_sina, stock_hk_index_spot_em, and index_global_spot_em, there is no selection criteria or exclusionary note. The only hints are the source URL and market scope, which are implicit and not actionable.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type, but no additional behavioral traits such as data freshness, rate limits, or dependencies. Given the annotations, a score of 3 is appropriate—it adds some value but not rich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single purpose line, a source URL, and return type information. It is front-loaded, contains no fluff, and every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description gives only a high-level return type ('城市映射' as pandas.DataFrame). It does not detail the structure of the mapping (e.g., city names/IDs) or explain how this tool supports sibling air quality tools. For a simple no-param read-only tool, it is adequate but leaves gaps in contextual linkage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100% and there is nothing to explain. The description clarifies the return as a city mapping DataFrame, which is useful. Baseline 4 applies for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '真气网-空气质量历史数据查询-全部城市列表' (Air quality historical data query - all city list) and specifies the return as a city mapping (城市映射) in a pandas DataFrame. This distinguishes it from sibling tools like air_quality_hist and air_quality_rank, which handle historical data and rankings respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs. alternatives. It does not mention that this tool provides the city list needed for other air quality tools (e.g., to get city codes before querying historical data). The usage context is entirely absent.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it specifies the return type as pandas.DataFrame and describes the filtering behavior for city (empty string returns all regions, a specific city name returns that city's data). It also includes the source URL, providing additional context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with the core purpose stated in the first line and additional return details in two lines. The inclusion of a raw URL adds some clutter but is not excessive. It is front-loaded with the tool's name and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description only states the return type (pandas.DataFrame) but not the columns, units, or content of the returned forecast data. The city parameter inconsistency also leaves the expected inputs ambiguous. While the core purpose is clear, the description lacks sufficient detail for full self-contained understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, yet the description mentions a 'city' parameter (city = '', city='唐山市') in the return section, implying the tool accepts an argument that the schema does not define. This conflicts with the structured definition and could mislead the agent into passing a parameter that fails validation. The baseline for 0 params is 4, but the misleading parameter reference reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides Hebei Province air quality forecasts for the next 6 days, distinguishing it from sibling tools like air_quality_hist and air_quality_rank. It identifies a specific resource (Hebei air quality forecast system) and time horizon, making the purpose explicit and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for forecast data (空气质量预报) but does not explicitly state when to use it over alternatives or mention exclusions. Sibling tools are not referenced, so usage guidance is only implied, not explicit.
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 already declare the tool as read-only, open-world, idempotent, and non-destructive, so the description does not need to repeat that. The description adds the source URL and the fact that the return is a pandas DataFrame containing trading rules, which is useful context. However, it does not disclose error handling, network dependencies, or any side effects, which would be extra value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured using a standard docstring format: title, source URL, parameter docs, and return docs. Each line serves a purpose without fluff, making it easy to scan. It is concise yet complete for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and no output schema, the description adequately covers both inputs and states that the return is a DataFrame of trading rules. However, it does not explain the default symbol value or give an idea of the DataFrame's columns, leaving some ambiguity about the exact output structure. Still, it is sufficient for an agent to invoke the tool and interpret the basic result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (coverage 0%), so the description carries the full burden. It clearly documents both parameters: symbol as the fund code, and indicator with an explicit enumeration of valid Chinese labels (e.g., '交易状态', '申购费率（前端）'). This fully compensates for the schema's lack of detail and gives the agent precise input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool provides fund purchase information (购买信息) from a fund profile, with a specific source URL and a return type of trading rules. It lists the exact scope via the indicator parameter, but does not explicitly differentiate it from sibling tools like fund_purchase_em, so it misses the distinctiveness bonus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other fund-related tools, nor does it mention any exclusions or alternative tools. It simply lists parameters and their types, leaving the agent to infer usage from the name and parameter names.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose any special behavior like pagination, date range, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with title, URL, params, and return sections, but the first line and the return line are almost identical, creating redundancy. It could be tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one parameter and no output schema. The description provides the source, parameter semantics, and return type, which is adequate for basic usage, but it doesn't describe the DataFrame columns or any additional options. Given the simplicity, it's minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden for the symbol parameter. It explains that symbol is a money fund code and that valid values can be obtained from fund_money_fund_daily_em, which is helpful for the agent. However, it doesn't specify the format beyond the schema's string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '基金数据-货币型基金收益-历史净值数据' (fund data - money fund yield - historical net value data), clearly identifying the resource and scope. It includes the source URL, and the specification of '货币型基金收益' distinguishes it from other fund tools like fund_money_fund_daily_em or fund_money_rank_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a pointer for obtaining the symbol via fund_money_fund_daily_em, but it does not explicitly state when to use this tool versus alternatives. The intended use is implied by the title, but no exclusions or comparison with other sibling fund tools 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the source URL and return type (pandas.DataFrame), providing some practical context, but it does not disclose data freshness, schema details, or any limitations beyond what the 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and front-loaded with the title and URL. Every line serves a purpose (title, URL, return type), but it lacks a structured, explanatory format. It is concise without being verbose, though it could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool, the description adequately conveys the data source and expected output type. With no output schema present, it at least states the return is a pandas.DataFrame of fund subscription statuses. However, it could be more explicit about the DataFrame columns or the nature of the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete with 100% coverage. There are no parameter semantics to explain; the baseline of 4 applies because the absence of parameters removes the need for additional documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving fund purchase/subscription status from the Eastmoney TianTian Fund website, with a direct URL and return type. The specific resource (基金申购状态) is unambiguous and easily distinguishes it from sibling fund tools like fund_aum_hist_em or fund_rank_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any mention of intended use cases or exclusions. The description merely states what it returns without contextualizing its role among the many fund-related 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds the official DCE URL and return type (dict), but does not disclose any additional behavioral traits such as rate limits, pagination, or data structure details. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes a redundant first line that exactly repeats the title, and the URL is helpful but not essential. The docstring structure is clear and easy to parse, making it mostly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers the core purpose and parameter meaning. However, it does not describe the structure or content of the returned dict, which would be helpful since no output schema is available. The sibling context clarifies exchange-specific scope, but the description itself lacks depth on return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the date parameter, but the docstring fully compensates by explaining it is the trading day, giving a concrete format example ('20200702'), and specifying the type as string. This is particularly valuable given the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the Dalian Commodity Exchange (DCE) warehouse receipt daily report for a specified date. The hierarchical label and return statement specify both the resource and the scope, and the DCE prefix distinguishes it from sibling warehouse receipt tools for other exchanges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 futures_warehouse_receipt_czce for other exchanges. The description merely states what it returns, but does not give context about typical use cases, prerequisites, or exclusions.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavior context by including the data source URL (Sina Finance), specifying that data is real-time, and confirming the return type as pandas.DataFrame. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a data source URL and parameter/return documentation. However, the overall description and return line repeat nearly identical phrasing ('期货品种当前时刻所有可交易的合约实时数据'), adding slight redundancy but not significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature, annotations, and a brief description that covers purpose, parameter, and return type. However, it lacks usage context to differentiate it from several similar sibling tools (e.g., futures_zh_spot, futures_main_sina) and does not describe the output columns or any limitations. For an agent selecting among many futures tools, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains the 'symbol' parameter as a futures variety name and directs users to ak.futures_symbol_mark() for the full list of valid names. This adds meaningful value beyond the input schema, which only provides a default value (PTA) with no description. The parameter semantics are clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves real-time data for all tradable contracts of a futures variety at the current moment. The verb is implied and the resource is specific ('期货品种当前时刻所有可交易的合约实时数据'). It does not explicitly distinguish itself from sibling tools like futures_zh_spot, which may also provide real-time futures quotes, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mentions how to obtain the symbol parameter via ak.futures_symbol_mark(), which is a prerequisite rather than usage context. There are no exclusions or comparisons to other futures real-time tools, making selection ambiguous.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: default dates to today, supported date formats, the market list with defaults, and return type as pandas.DataFrame. This goes beyond annotations, though it does not discuss edge cases like empty results or data source specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with a one-line summary followed by parameter documentation. It is front-loaded and free of fluff, though the return description repeats the summary phrase. Overall, it earns its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lacks details about the return DataFrame's columns or contents, which would help the agent anticipate what data arrives. It does cover parameters and defaults well, but without usage guidance or return structure, it leaves notable gaps. A mention of typical columns or data coverage would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility. It provides detailed docstrings for all three parameters: accepted date formats (YYYY-MM-DD, YYYYMMDD, or datetime.date), default behavior when empty, and an explicit list of market codes with their meanings. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '交易所日交易数据' (exchange daily trading data) and documents parameters for fetching daily data. It clearly conveys the resource and action, though it uses a noun phrase rather than a verb. It implicitly distinguishes from exchange-specific siblings like get_cffex_daily by supporting a market parameter, but 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as get_cffex_daily or get_shfe_daily. The description only explains parameters and defaults, leaving the agent to infer that this tool covers multiple exchanges. No exclusions or context for selection are provided.
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?
The annotations already mark this as readOnly, idempotent, and non-destructive, and the description adds meaningful behavioral context: note 1 explains that SHFE and CFFEX rankings are aggregated from instrument totals rather than being true variety totals, and note 2 notes that DCE does not publish instrument-level rankings. This goes beyond the structured fields and sets accurate expectations about data limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose line, two important notes, then parameter/return documentation. Each section serves a clear function and the most critical caveats are front-loaded. It is longer than a typical description, but the extensive column listing is useful given there is no output schema, and nothing seems redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with two parameters, it explains parameter formats, return type, and key aggregation caveats. However, the return column listing is incomplete (stops at vol_top10 even though the title implies top15/top20 fields), and the five exchanges are not explicitly named. Since there is no output schema, these gaps leave some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives no descriptions for either parameter, so the description carries the full burden. It explains acceptable date formats (YYYY-MM-DD, YYYYMMDD, datetime.date) and the empty-date behavior (defaults to today), as well as vars_list format with an example (['RB','AL']) and the empty-list behavior (all commodities). This compensates well for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it collects top 5/10/15/20 member position ranking data from five futures exchanges (采集五个期货交易所前5、前10、前15、前20会员持仓排名数据). The caveats (注1 and 注2) further specify what is being returned at an aggregated level. However, it does not explicitly contrast this with sibling per-exchange ranking tools, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context about the aggregation methodology and exchange-specific limitations, which indirectly helps an agent infer when to use this tool (e.g., when cross-exchange aggregated rankings are needed). It does not explicitly say 'use this when' or 'use alternatives instead,' so the guidance remains 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds a source URL and return type (pandas DataFrame), but does not disclose any potential network dependencies, update frequency, or data structure quirks. This is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and follows a standard docstring format, including a URL and parameter documentation. Every line serves a purpose, though the format is slightly verbose with separate type and return lines. Overall it is well-structured and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter data retrieval tool, the description covers the essential information: source, parameter values, and return type. However, without an output schema, it does not specify the DataFrame's columns or whether historical time series vs. latest values are returned. This leaves some ambiguity for an agent needing exact data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a default value with no enum or description, so the description carries the full burden. It explicitly lists all four allowed symbol values (周指数, 月指数, 季度指数, 年度指数) and labels the parameter type as string. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a tool for retrieving China highway logistics freight price index data, with a source URL and return type. The name and description together distinguish it from sibling index_volume_cflp, which targets volume data. The parameter choices (weekly/monthly/quarterly/yearly) further specify the resource granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to choose this tool over alternatives. While the parameter choices indicate possible frequency selections, there is no mention of use cases or exclusions, such as when index_volume_cflp 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a source URL and return type (pandas.DataFrame), but no further behavioral details such as data freshness, pagination, or potential errors, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter specification, and return type. Each element provides necessary information with no redundancy, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 provides the essential parameter choices, return type, and data source. It does not describe DataFrame contents or update frequency, which could be useful but are not critical for basic realtime quote retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'symbol' parameter with no description, and schema coverage is 0%. The description fully compensates by listing the exact allowed values (市场表征, 一级行业, 二级行业, 风格指数, 大类风格指数, 金创指数) and stating the parameter type as string, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as providing realtime market data for the Shenwan Hongyuan index series (指数系列实时行情数据) with a specific source URL. However, it lacks an explicit verb like 'fetch' or 'retrieve', and does not explicitly differentiate from sibling index tools, though the name and context imply 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool over alternatives. The description only lists parameters and return type, with no 'use when' or comparison to the many sibling index tools, leaving the agent to infer usage from the name and context.
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 already declare safe read-only, idempotent behavior. The description adds that it returns the latest weights only, not historical data, and specifies the data source. However, it does not disclose any rate limits, error cases, or additional side effects, though these are less critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a title, URL, and docstring-style param and return sections. Each part is useful, though the URL and title are slightly redundant with the parameter default. Overall, it is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description explains the return type (pandas DataFrame) and content (constituent weights), and that it is the latest data. It could specify columns or sorting, but the core usage context is sufficiently covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides type and default for symbol. The description enriches this by explaining symbol is an index code and pointing users to ak.index_stock_info() for valid values, which goes beyond the bare schema and helps correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the latest constituent stock weights for CSI indices, with a specific source URL. It distinguishes itself from sibling tools like index_stock_cons_csindex (which likely returns constituent lists) by focusing on weights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mentions how to obtain the symbol via ak.index_stock_info(), but does not explain trade-offs with sibling tools like index_stock_cons_sina or index_stock_cons.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL (https://yun.ccxe.com.cn/indices/nei) and the return type (pandas.DataFrame), providing useful context about the data origin and output format. There is no contradiction with annotations, and the behavioral traits are sufficiently disclosed for this simple read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first line states the index name, followed by a source URL and return type. Every line carries meaningful content with no fluff. While it is very short, it is appropriately sized for a no-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description could be more complete about what the returned DataFrame contains. It only states '科技投入指数' without describing columns, time range, or granularity. The large number of sibling index_*_cx tools also suggests that a bit more differentiation would help, though the explicit index name and URL provide some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 any parameters, and the input schema is empty. The description adds no param-related information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the specific resource: '财新数据-指数报告-科技投入指数' (Caixin Data - Index Report - Technology Investment Index) and indicates the return type as a pandas DataFrame. It is specific about the data source and index, but the verb 'return' is implicit rather than an explicit 'get' or 'fetch'. It does not distinguish itself from sibling index_*_cx tools beyond the index name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description does not state when to use this tool vs alternatives like index_ai_cx or index_si_cx. The intended use is implied by the index name ('科技投入指数'), making it clear that this tool is for retrieving the technology investment index, but no exclusions or context are given.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the data range starts from 19990401 and that the return is a pandas Series of current values in percent, plus source URLs. It doesn't contradict annotations and provides useful context about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with core info and URLs, no redundancy. It's front-loaded with the main idea.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read-only tool, the description covers the essential aspects: what data, range, return type, and source. It doesn't mention language or potential data updates, but that's minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers them (100% coverage). The baseline for zero parameters is 4; the description additionally clarifies the return format but no parameter syntax is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides the New Zealand Federal Reserve (RBNZ) interest rate decision report, covering data from 19990401 to present, returning the current value in percent as a pandas Series. The tool name and description align, but it doesn't explicitly differentiate it from sibling macro_bank_* 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/5Does 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 other central bank interest rate tools (e.g., macro_bank_australia_interest_rate). No alternatives, exclusions, or prerequisites are mentioned.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful context by specifying the data range (20030601-至今), source URLs, and the return type (pandas.Series) with unit (%), which helps an agent understand the nature and format of the data beyond basic safety flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the report name and data range, but it includes two source URLs that are not essential for tool invocation or usage. It also repeats the title from the annotations, adding slight redundancy. Overall, it is concise but has a bit of clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter, read-only data retrieval tool, the description provides sufficient context: data coverage, return type, and value meaning. It lacks explicit mention of the series index or historical date structure, but the :rtype indicates a pandas.Series, which is likely adequate for an agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. The description adds no parameter details, but none are needed. The baseline for zero-parameter tools is 4, and the description does not need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Russia's interest rate decision report with a data range from 20030601 to the present, and states the return value as current value (%). It is distinguishable from sibling tools by the country-specific name and content. However, it lacks an explicit action verb (e.g., 'Get' or 'Retrieve'), so it reads more like a title than a directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives for other countries' interest rates. It implies usage through the name and data range, but provides no exclusions, comparisons, or guidance on selecting this over sibling tools like macro_bank_usa_interest_rate.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the source URL and return type (pandas.DataFrame), providing some extra context but no additional behavioral details such as data range or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and free of fluff, containing the data source, return type, and a brief descriptor. The line breaks are slightly awkward but do not detract from its efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description adequately identifies the data (Canada yearly CPI) and return format (DataFrame). It lacks details on the exact data columns or time range, but such details are less critical for a simple data fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% with an empty schema. The description correctly notes the return type and data source, which is sufficient given no parameters require explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching Canada's yearly Consumer Price Index (CPI) rate from Eastmoney. It is specific to the yearly CPI metric, distinguishing it from siblings like macro_canada_cpi_monthly and macro_canada_core_cpi_yearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., monthly CPI or core CPI). It simply names the data source and return type without contextual use cases 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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the data range and source URL, but doesn't disclose potential output size or any quirks beyond the return type. This is acceptable given the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the main statement in one line, followed by a source URL and return type in docstring format. It is front-loaded with the essential information and contains no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description provides the data range, source, and return type (DataFrame). It could mention the exact columns or units, but the absence of an output schema is compensated by the clear statement of what is returned. Overall, it is sufficiently complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation needed. The schema is empty, and the description does not need to explain parameters; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns China's annual PPI data with a specific date range (19950801 to present), which clearly identifies the resource. It distinguishes from sibling tools like macro_china_ppi by specifying '年度' (yearly), though it lacks an explicit verb like 'get' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is implied by the name and description, but there is no explicit guidance on when to use it versus alternative PPI tools (e.g., macro_china_ppi for monthly data). The data range and source URL provide some context, but no direct alternative comparisons or exclusion criteria are given.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, and the description adds the source URL and return type (pandas.DataFrame). This confirms it's a safe read operation returning tabular data, adding context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the tool's purpose, but it includes a raw URL and docstring-style return statements that could be more polished. It's reasonably concise but not exceptionally structured, with a few lines that carry limited value for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, clear annotations, a source URL, and return type indication, the description is complete enough for an agent to understand what data will be returned and that it's a safe read operation. It lacks details like time range or columns, but with no params and a well-known metric, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (vacuously). The description references the return type and data source, and with no params, it doesn't need to explain parameter semantics; the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves money supply data from Sina Finance China macro economy, with the title confirming the specific metric. However, it doesn't explicitly differentiate from the sibling tool 'macro_china_money_supply', which appears to serve a similar purpose, so it's clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a source URL and return type, implying it's used to fetch this specific dataset, but provides no explicit guidance on when to use it versus alternatives like 'macro_china_money_supply'. Context is clear for this specific data, but no exclusions or alternative recommendations are given.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context: the specific data range, the quirk that the first two values need to be dropped, and the return type (pandas.Series). This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but slightly cluttered with raw URLs and a repeated title. It front-loads the purpose, but the middle includes source links that could be considered optional. Still, every sentence provides some useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter data retrieval tool, the description provides the data range, source URLs, unit of measurement, a data-cleaning instruction, and the return type. It is fairly complete, though it does not explicitly mention frequency or update schedule; the tool name implies month-over-month.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description confirms no parameters are needed and explains the return unit, which is adequate given the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns the Eurozone current account report (欧元区经常帐报告) with the current value in 亿欧元, and the tool name includes '_mom' indicating month-over-month. This clearly identifies the data resource, though it doesn't explicitly contrast with sibling tools like macro_euro_trade_balance or macro_euro_cpi_mom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage note: the data range starts from 20080221 to present and the first two values must be removed. However, it gives no explicit guidance on when to choose this tool over other eurozone macro indicators or any exclusions.
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?
The description adds useful context beyond annotations: it specifies the data range (20140702 to present), provides source URLs, and indicates the return type (pandas.DataFrame). Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The additional details help set expectations about data provenance and structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a single line for the title and short docstring-style lines for return info. The two source URLs add value but are somewhat redundant with the title. Overall, it is front-loaded and every line is informative, though slightly repetitive in the return description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description covers the essential facts: what data, date range, and source. However, it does not describe the columns or structure of the DataFrame, nor update frequency or refresh behavior. Since there is no output schema, this missing detail could leave an agent uncertain about how to interpret the result. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the guidelines, the baseline for 0 parameters is 4, and the description does not need to add parameter semantics. It correctly omits any parameter-related text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an LME inventory report with a specific date range, which distinguishes it from sibling tools like macro_euro_lme_holding (holdings report). It lacks an explicit verb but the noun '库存报告' (inventory report) plus return type makes the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: the tool provides LME inventory data, so an agent would use it when needing that specific dataset. However, there is no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites. For a zero-parameter tool this is acceptable but not exemplary.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the tool's safety profile. The description adds the data range and return format, but does not disclose additional behavioral characteristics such as data freshness, update frequency, or any network dependencies. This is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loads the key identification of the report before providing source URLs and return type. However, it includes two URLs that add some clutter, and the structure could be slightly tighter, so it does not achieve a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool, the description is sufficiently complete: it states the metric, the historical data range, the return value, and the return type. It omits minor details like release frequency or exact data source semantics, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema correctly reflects that with no properties. Since there are no parameters to document, the baseline of 4 applies, and the description is not required to explain parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides the Eurozone retail sales month-over-month report (欧元区零售销售月率报告), with an explicit data range from 20000301 to present. It specifies the return value as the current value in percent and the return type as pandas.Series. This distinguishes it from sibling tools such as macro_euro_cpi_mom or macro_uk_retail_monthly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool compared to alternatives. It does not mention use cases, exclusions, or relationships with sibling macro tools, leaving the agent without selection context beyond the tool's name and basic purpose.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect transparency. The description adds useful context by specifying the source URL and the return type (pandas.DataFrame), which is not in the annotations. However, it does not disclose potential data ranges, refresh frequency, or other behavioral nuances, so it only partially adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a short source label, a URL, and a docstring return specification. It is front-loaded with the main purpose and contains no redundant words. Every line earns its place, making it an efficient, well-structured description for a simple data-retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a zero-parameter tool and the presence of annotations covering safety, the description is mostly adequate. However, it lacks details about the returned DataFrame's contents beyond 'consumer price index monthly rate final value'—such as date range, units, or historical depth. Since there is no output schema, this information would be helpful for the agent to know what to expect, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is vacuously 100%. According to the scoring guideline, a baseline of 4 is appropriate for a zero-parameter tool. The description does not need to explain any parameter semantics, and it doesn't contradict the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: it retrieves the Germany Consumer Price Index (CPI) monthly rate final value from East Money's data center. The resource (specific geographic region and metric) is unambiguous, and it distinguishes itself from siblings like macro_germany_cpi_yearly by specifying 'monthly' and 'final value'. The docstring return statement reinforces the action of returning a DataFrame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only states the data source and what is returned, with no mention of use cases, exclusions, or comparisons to related tools. In a sibling set containing many macro indicators, the agent receives no explicit direction for selection.
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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful context by specifying the data range and source URL, but does not disclose any additional behavioral traits such as column structure, update frequency, or potential limitations. This is adequate given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (about 3 short lines) and includes essential information: title, data range, URL, return type. While the structure is a bit fragmented with docstring-style :return: and :rtype:, every element adds value and no unnecessary filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is sufficiently complete. It specifies the data source, availability period, and return type as a pandas DataFrame. For a straightforward data retrieval tool, this covers the key information an agent needs for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0-parameter tools is 4, and the description does not need to add parameter semantics. The description appropriately focuses on the output and source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Jin10 Data US GDP report, specifies the data range (20080228 to present), and provides a source URL. The resource (US GDP) is specific and unambiguous, distinguishing it from sibling tools like macro_usa_cpi or macro_china_gdp without any confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool returns, not when to use it relative to other macro economic tools. There is no mention of alternatives, prerequisites, or exclusion conditions. An agent must infer usage solely from the tool name and general context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data range and return type (pandas Series, current value %), but does not disclose other behavioral traits like update frequency or potential data limitations. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the report name and data range, followed by a source URL and return type. It avoids unnecessary fluff, though the URL line is somewhat extraneous but still useful for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter data retrieval tool, the description covers the essential aspects: what it returns (US import price index), the time range, the source URL, and the return format. It doesn't explain the exact columns or update schedule, but the output schema is absent and the tool's simplicity reduces the need for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty schema). The description adds context about the returned series (今值(%) and pandas.Series), which is sufficient. With no parameters to explain, a score of 4 reflects the baseline for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the US import price index report data series, with a specific resource and coverage period (19890201-present). The name and description together make it distinct from sibling tools like macro_usa_export_price and other macro_usa_* 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/5Does 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 such as macro_usa_export_price or other macro indicators. It only describes the data content, leaving the agent to infer usage from the name and sibling structure.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the date range and return type (DataFrame), which is useful context, but does not disclose update frequency, coverage limitations, or whether data is seasonally adjusted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact but repeats the report name in the title and the return docstring. The URL and date range add useful context, but the duplication could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless report retrieval tool, the description provides essential facts: what data, date range, source, and return type. Missing details like column names or units, but given simplicity and annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so description does not need to explain them. Schema coverage is 100% (empty 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as retrieving the US Markit Manufacturing PMI preliminary report, with a specific date range (20120601 to present) and source URL. It distinguishes from sibling PMI tools (ISM PMI, services PMI, China PMI) by specifying Markit, manufacturing, and preliminary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like macro_usa_ism_pmi or macro_usa_services_pmi. The description provides data range and source but does not mention selection criteria 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, providing safety context. The description adds the official source URL and the pandas.DataFrame return type, which are helpful, but it does not disclose other behavioral details like update frequency, potential delays, or data completeness. It adds some value without fully going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary, the source URL, then parameter and return type docstrings. Every sentence provides necessary information without redundant prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only data retrieval tool with one optional parameter, the description is largely complete: it gives the source, parameter choices, and return type. It does not describe the columns of the DataFrame or clarify that '当日行情' means current-day data only, but the simplicity of the use case and the provided URL mitigate this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines symbol as a string with a default, giving zero description. The tool description compensates fully by explicitly listing all five valid values for symbol (华夏上证50ETF期权, 华泰柏瑞沪深300ETF期权, 南方中证500ETF期权, 华夏科创50ETF期权, 易方达科创50ETF期权) and specifying the type. This is essential information the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns intraday quotes for SSE option underlyings ('期权标的当日行情'), with a specific source URL and a list of valid symbols. It clearly identifies the data resource and scope, but does not explicitly distinguish it from similar sibling tools like option_sse_underlying_spot_price_sina, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives, or any exclusions. The description only explains what the tool does and lists parameter choices, leaving the agent to infer usage context. This is below the 'clear context' threshold.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the return type (:rtype: pandas.DataFrame) and a source URL (https://www.soozhu.com/price/data/center/), which are useful behavioral details beyond the safety annotations. It does not cover pagination or rate limits, but the return-type disclosure earns a strong score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the title, source URL, return description, and return type. Every line provides useful context with no filler or redundant text. This is perfectly sized for a zero-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only data tool, the description provides essential information: the data subject (national corn price trend), the source (Soozhu), and the return type (pandas.DataFrame). However, it lacks detail on the DataFrame's columns, date range, or frequency. Given the absence of an output schema, a bit more structure would be ideal, but the tool's simplicity and strong annotations keep it at a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the rubric sets a baseline of 4. The input schema is empty and trivially 100% covered, so there is no parameter information for the description to add. The description need not compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '全国玉米价格走势' (national corn price trend) and notes it returns a pandas DataFrame, making it evident this tool provides corn price trend data from Soozhu. It distinguishes from sibling tools like spot_hog_soozhu by the 'corn' resource, but lacks an explicit verb such as 'get' or 'retrieve', so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention that it complements or differs from related Soozhu price tools (e.g., spot_soybean_price_soozhu, spot_hog_soozhu), nor does it describe appropriate contexts or prerequisites. The only implied usage comes from the tool name and resource description, which is insufficient.
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 annotations already declaring safety (readOnly, idempotent, non-destructive), the description adds the data source URL and return type (pandas.DataFrame). It does not disclose whether the data is real-time or historical, or the DataFrame's structure, so behavioral transparency is minimal beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a source URL, parameter documentation, and return type. It is appropriately sized and front-loaded with the title and source, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, safe annotations, and no output schema. The description covers the source, allowed symbols, and return type, but lacks details on the DataFrame's columns and whether the data is current or historical, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a 'symbol' parameter with a default and no description, but the description explicitly lists the three valid Chinese symbol choices and the parameter type, providing essential semantic information for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 'Sina Finance - Commodity Spot Price Index' and includes a source URL and return type, making it clear that the tool retrieves spot price index data. However, it lacks an explicit verb like 'fetch' and doesn't differentiate from sibling spot/futures tools, so it's clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool over alternatives, nor does it state any exclusions. It implies usage through the allowed symbol choices, which narrows its scope, but no explicit guidance on selecting this tool vs others is 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?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the source URL and return type (pandas.DataFrame) but does not disclose additional behavioral traits such as rate limits, data freshness, or potential network dependencies. For a simple read-only tool with annotations, this is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, source URL, return value description, and return type. Every line serves a purpose, and there is no redundant or filler content. It front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the full burden of explaining what the tool returns. It clearly states that it returns all concept sector names and links in a pandas.DataFrame, which is sufficient for a simple list tool. It could be slightly more explicit about the exact column names, but the current description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is trivially fully covered. The description is not required to explain parameters, and it doesn't attempt to. The baseline for zero-parameter tools is 4, and the description appropriately focuses on what is returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns '所有概念板块的名称和链接' (names and links of all concept sectors) from 同花顺 (THS), which is a clear verb+resource. The source (THS) and scope (concept sectors) distinguish it from sibling tools like stock_board_concept_name_em and stock_board_industry_name_ths, though it does not explicitly name these 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining the full list of THS concept sector names and links, providing clear context. However, it offers no explicit guidance on when to use this over other sibling tools (e.g., stock_board_concept_info_ths for details or stock_board_industry_name_ths for industry sectors), 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the URL and the parameter semantics (time-range choices), but no additional behavioral traits such as data freshness, pagination, or limitations. This is acceptable but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: title, URL, parameter specification, return type. Every line contributes useful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 rich annotations, the description provides enough to invoke it correctly. It lacks column details or data examples for the returned DataFrame, and there is no output schema, but the URL and parameter choices give adequate context for a straightforward data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists symbol as a string with a default, but the description's docstring enumerates the exact permitted values ('当前交易日', '近3日', '近5日', '近10日', '近30日') and specifies the return type. This fully compensates for the 0% schema description coverage, making the parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the data source (Eastmoney), the domain (block trades), and the specific data set (active business department statistics). It is clear enough to distinguish from generic data tools, though it does not explicitly differentiate from sibling block trade statistics tools like stock_dzjy_hygtj or stock_dzjy_yybph. The verb is implied but the resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the parameter choices (time ranges) but does not state when to prefer this tool over alternatives, nor any exclusions or prerequisites. There is no guidance on scenarios where this specific statistic is appropriate versus other block trade data 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds the allowed symbol choices and pandas DataFrame return type, but no further behavioral details such as pagination or request 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the Chinese title, followed by a URL and docstring. Every sentence serves a purpose with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers parameter choices and return type. It lacks column details or a more precise description of the ranking data, but is adequate given the simplicity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'symbol' parameter with no description or enum, and schema coverage is 0%. The description compensates by explicitly listing all valid choices: 近一月, 近三月, 近六月, 近一年, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a block trade business department ranking from East Money's data center, with a URL and return type. It distinguishes from sibling block trade tools by scope, but lacks an explicit verb such as 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other block trade tools like stock_dzjy_mrmx. The description only provides the data source and parameter choices, with no alternatives, exclusions, or usage context.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds that the return type is pandas.DataFrame and that it contains historical trends and fan characteristics, which is useful but minimal. There is no detail on data granularity, columns, or potential pagination, so it only partially exceeds annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line title, a reference URL, and a compact docstring with parameter and return type. Every sentence is informative without unnecessary verbosity, and the structure follows a clear pattern (title, source, param, return).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description provides enough context: it names the source (Eastmoney), the data content (historical trends and fan characteristics), the required parameter format, and the return type. It lacks specifics about the DataFrame structure or date range, but given the simplicity of the tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. The docstring explains 'symbol' as a security code with market representation ('带市场表示的证券代码') and provides an example default 'SZ000665'. This adds meaning beyond the bare schema type and default, clarifying the expected format (exchange prefix + code).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical trends and fan characteristics for a stock's popularity ranking on Eastmoney. The verb is implicit but the resource is specific ('个股人气榜-历史趋势及粉丝特征'), distinguishing it from real-time rank tools like stock_hot_rank_detail_realtime_em. However, it does not explicitly mention alternative sibling tools, so it loses one point for full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical analysis ('历史趋势') but provides no explicit guidance on when to choose this over real-time rank tools or other popularity tools. There are no stated exclusions or alternatives, so the context is implied rather than explicitly directed.
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 already provide strong safety signals (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description does not contradict these. However, the description adds only the source URL and return type, without disclosing potential behavioral traits such as data freshness, pagination limits, or whether the ranking is real-time. With annotation coverage, a score of 3 reflects the minimal added context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short lines that include the Chinese title, the source URL, and the return type/value. Every line provides distinct, useful information without redundancy or filler. This is an example of appropriate minimalism that prioritizes scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description gives the essential facts: what data is returned, its source, and its type. However, it lacks details about the returned DataFrame's columns, the ranking criteria, or any caveats (e.g., real-time vs. delayed). Given the simplicity, this is a minimum-viable description but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and the description is 100% covered by the schema (trivially). The baseline for 0-param tools is 4, and the description includes a docstring-style return type, though no parameter info is needed. The description could not add value here since there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '东方财富-个股人气榜-飙升榜' and provides the source URL, clearly identifying it as the Eastmoney individual stock popularity surging list. This distinguishes it from sibling hot-rank tools, which typically target different ranking metrics or markets. The return type and value are also specified, leaving no ambiguity about the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or contrast with sibling tools like stock_hot_rank_em or stock_hot_rank_detail_em. Usage context is only implied by the tool name and source URL, which is insufficient for an agent to decide between similar ranking 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is well-covered. The description adds the specific data source URL and return type, which is useful, but it does not disclose additional behavioral traits such as data freshness, pagination, or rate limits. This is adequate but not rich, consistent with the lower bar set by strong annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: source name, URL, and return type in three short lines. Every sentence carries essential information with no filler or redundancy. It is a model of concise documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, strong read-only annotations, and no output schema, the description provides sufficient context: it states the data source, the exact URL, and the return type. It lacks specifics about the returned DataFrame's columns or time range, but for a zero-parameter data summary tool, this is acceptable. Slightly more detail on update frequency or data scope would push it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description confirms that no inputs are needed and that the return is a pandas DataFrame. With 0 params, the baseline is 4, and the description adds no unnecessary parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving 沪深港通资金流向 (HSGT fund flow) from Eastmoney's data center, with a specific URL. It names a specific resource and return type (pandas DataFrame), making the purpose unambiguous. However, it does not explicitly distinguish itself from the many sibling HSGT tools (e.g., stock_hsgt_fund_min_em, stock_hsgt_hist_em), so it misses the explicit differentiation that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The source path and URL imply the tool is for retrieving historical/current HSGT fund flow summary data, which gives a contextual sense of when to use it. However, there is no explicit guidance on when to choose this tool over alternatives, no exclusions, and no mention of alternatives. Usage context is implied but not articulated.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, read-only operation. The description adds that the return type is a pandas.DataFrame and provides the data source URL, but it does not disclose any additional behavioral traits like data freshness, pagination, or network dependencies. This adds modest value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title, source URL, return description, and return type. Each line serves a purpose, and it is front-loaded with the most important information. No redundant or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless data retrieval tool, the description is sufficiently complete. It specifies the data source, the nature of the data (HK IPO subscription and allotment), and the return type. While it does not detail the DataFrame columns, the low complexity and supporting annotations make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% coverage (vacuously). With no parameters to document, the baseline of 4 applies, and the description correctly focuses on the return value rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states this tool retrieves Hong Kong IPO subscription and allotment data from the Tonghuashun Data Center, with a specific URL and return type. It clearly identifies the resource (HK IPO data) and the source (THS), distinguishing it from sibling tools like stock_ipo_ths or stock_xgsr_ths. However, it lacks an explicit verb like '获取' or 'retrieves', relying on the context of returning a DataFrame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for accessing HK IPO subscription and winning data, but it does not provide explicit guidance on when to use it versus alternatives such as stock_ipo_ths, stock_xgsr_ths, or other IPO data tools. No exclusions or alternative tool references are mentioned, leaving usage context only implied.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the return type (str) and how the symbol is sourced. It doesn't disclose potential issues like rate limits or invalid question IDs, but for a simple read-only retrieval this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the Chinese title. It uses a docstring format with a URL example, which is somewhat noisy but not overly long. Every line adds some value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description covers the main purpose, how to get the parameter, and the return type. However, it lacks details on error handling, data format specifics, or any caveats (e.g., real-time vs historical), leaving gaps that could cause mis-invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that symbol is a questioner number (though likely actually a question ID) and instructs users to obtain it via stock_irm_cninfo(). It also specifies type str. This provides actionable meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as '互动易-回答' (Interactive Q&A - Answer) and states it returns an answer (回答). It distinguishes from the sibling tool stock_irm_cninfo by instructing the user to obtain the symbol from that function. However, the label '提问者编号' (questioner number) may be ambiguous; the URL parameter suggests it's a question ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit dependency chain: call ak.stock_irm_cninfo() to obtain the symbol, then use this tool. This helps the agent understand the workflow. However, it doesn't explicitly state when not to use this tool or describe alternative approaches.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds that it returns a pandas.DataFrame and includes the source URL, but it does not describe potential caveats like date validity or result contents beyond '标的证券信息'. This is adequate but not rich, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a title line, a source URL, and standard param/return docstring lines. No fluff or redundancy. It's appropriately sized for a one-parameter read-only tool, though it could be slightly more informative about output columns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with good annotations and a single parameter, this is mostly complete: it states the data source, the parameter meaning, and the return type. However, it does not describe the actual columns or contents of the returned DataFrame, and there is no output schema to compensate. This leaves the agent somewhat in the dark about the exact data structure, so a 3 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It defines the 'date' parameter as a '交易日' (trading day), which adds business meaning beyond the schema's plain string type. The default value '20221129' in the schema also suggests format, but the description itself doesn't explicitly state the YYYYMMDD format. Still, it meaningfully clarifies the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '深圳证券交易所-融资融券数据-标的证券信息' (Shenzhen Stock Exchange - Margin Trading Data - Underlying Securities Information) and includes the source URL. It distinguishes from siblings like stock_margin_underlying_info_bse by specifying the exchange in both the name and description. However, it lacks an explicit verb like 'get' or 'retrieve', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for SZSE margin trading underlying securities data, with a date parameter. The URL and title establish the intended use case without explicitly stating when not to use it or naming alternatives, which fits the 'clear context, no exclusions' level. It doesn't explicitly contrast with BSE/SSE counterparts, but the exchange is clearly identified.
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?
Annotations already indicate a safe, idempotent read operation. The description adds the data range starting from 2010-06-01 and the parameter format example, which provides useful context beyond the annotations. It does not contradict the annotations and discloses the return type as pandas DataFrame.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and follows a standard docstring structure with source URL, parameter documentation, and return type. It is not overly verbose, and each line provides relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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) and the presence of helpful annotations, the description provides adequate context: data source, parameter semantics, and return type. It does not describe the DataFrame columns, but this is not critical for such a simple data lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that the 'date' parameter is the data month and gives an example (2011-07-01), adding meaning beyond the bare schema which only lists a default value. However, the default in the schema is '20200731' without dashes, conflicting with the example format and leaving ambiguity about the accepted date format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data resource (券商业绩月报 from Eastmoney) and the URL, and the return type is specified as a pandas DataFrame. However, it lacks an explicit verb like 'retrieve' or 'get', relying on implied meaning from the docstring structure. It distinguishes from siblings by naming the specific dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the data source and parameter guidance, implying that this tool is for retrieving monthly brokerage performance data from Eastmoney. It does not explicitly state when to use this tool versus other stock data tools, nor does it 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL (https://data.eastmoney.com/xg/ipo/) and the return type (pandas.DataFrame), which is useful context beyond annotations. However, it does not disclose any additional behavioral traits such as data freshness, network requirements, or potential errors, which is acceptable for a simple data-fetch tool but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of four lines with no filler words. It front-loads the source and topic, followed by URL and return type. The only minor issue is the ':return: 北交所' line, which is vague and could be misinterpreted, but overall it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, so the description must carry the burden of explaining what is returned. It states the return type (pandas.DataFrame) and the topic (IPO review info), but the return value line '北交所' is unhelpful and does not enumerate columns or content details. Given the simplicity of a zero-param fetch, the description is adequate but leaves gaps about the actual data structure, which warrants a 3 rather than a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all parameters (trivially). Per the rubric, 0 params gets a baseline of 4. The description adds nothing about parameters, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as '东方财富网-数据中心-新股数据-IPO审核信息-北交所' (Eastmoney Data Center - IPO Review Info - Beijing Stock Exchange), which clearly specifies the data source and target market. The tool name 'stock_register_bj' further reinforces the Beijing exchange focus, distinguishing it from sibling register tools. However, it lacks an explicit verb like 'get' or 'list', relying on the implied DataFrame return type to convey retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for Beijing Stock Exchange IPO review data via the '北交所' label, and the sibling tools (stock_register_cyb, stock_register_kcb, etc.) suggest other markets. This provides clear context about when to use this tool, but it does not explicitly state alternatives or exclusions, which would earn a 5.
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?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context by disclosing known data errors for CIEN and AI in the 复权因子 (adjustment factor), and by clarifying the meaning of each adjust value. This goes beyond annotations and informs the agent of potential data quality issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but somewhat unstructured; the URL and notes are embedded in a block that mixes metadata, warnings, and parameter docs. It's not excessively long, but the organization could be improved. The content is valuable, but the presentation is a bit scattered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description provides sufficient context by stating the return type (pandas.DataFrame) and the meaning of the return based on adjust. The caveats about error-prone stocks add necessary context. It does not list columns or date range, but for a daily data tool, this is acceptable and the name implies the frequency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite zero schema description coverage, the description thoroughly explains both parameters: 'symbol' with guidance to use get_us_stock_name to obtain it, and 'adjust' with explicit value meanings (empty string for unadjusted, 'qfq' for forward-adjusted, 'qfq-factor' for factor data). This fully compensates for the absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool retrieves US stock daily data from Sina Finance, with the name 'stock_us_daily' and the Chinese title '新浪财经-美股'. It explicitly explains the 'adjust' parameter variants (unadjusted, forward-adjusted, factor), making the resource and scope clear. While it doesn't explicitly compare to siblings, the name and content sufficiently differentiate it from other US stock tools like spot or historical minute 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives. It only mentions that the symbol can be obtained via get_us_stock_name, which is a cross-reference but not a usage guideline. No explicit exclusions or conditions are provided.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a valuable behavioral warning about IP banning under heavy scraping, and provides a sample source URL. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and front-loads the purpose and IP warning. The parameter docstring is structured with :param/:type lines, which is easy to parse. It is slightly cluttered by the URL and docstring format, but every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameters thoroughly and states the return type (pandas.DataFrame). However, it describes the return value only as '行情数据' (market data) without specifying columns or structure, and there is no output schema. Given the tool's complexity, this is a noticeable gap but not fatal for a historical data retrieval function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description thoroughly explains each parameter: symbol format (e.g., 'sh600000'), date format (YYYYMMDD), and adjust options (qfq, hfq, etc.). This fully compensates for the schema gap and adds meaning far beyond mere parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: historical market data for individual A-shares from Sina Finance. The verb is implied rather than explicit (e.g., 'get' or 'query'), but the parameter list and return type make the function's purpose evident. It does not explicitly distinguish from sibling tools like stock_zh_a_hist, but the source (Sina) and daily granularity are noted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only behavioral caution is about IP bans from heavy scraping, which is a warning, not a usage distinction. There is no mention of preferred use cases, prerequisites, or exclusion conditions.
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 already establish read-only, idempotent, and non-destructive behavior. The description adds that the tool returns a pandas.DataFrame and explains adjustment modes (qfq/hfq), but it does not disclose limitations like data availability windows, rate limits, or column details. Thus it provides moderate added context but not rich behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a URL and parameter list, which is efficient and scannable. However, the line 'return: specific data' is vague and adds little value, and the title/annotations duplicate some content. It is concise but not optimally polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description's return information ('specific data', pandas.DataFrame) is insufficient to tell an agent what columns or time ranges to expect. It also omits any limitations, data source caveats, or guidance on selecting this tool among many similar stock data functions. The parameter details are strong, but overall context is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, making the description the sole source of parameter semantics. It comprehensively explains each parameter: symbol with example 'sh000300', period with valid values 1/5/15/30/60, and adjust with three modes (empty/qfq/hfq). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '股票及股票指数历史行情数据-分钟数据' (stock and index historical market minute data), making the tool's purpose evident. However, it lacks an explicit verb and does not differentiate from sibling tools like stock_zh_a_hist or stock_zh_a_hist_min_em, so it misses the full 5-point criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for minute-level historical data through its title and parameter explanation, but it does not explicitly state when to use this tool over alternatives or provide any exclusion guidance. Sibling tools with similar names exist, yet no comparative direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a critical behavioral warning not captured by annotations: repeated calls will lead to a temporary IP ban from Sina. It also specifies the return type as pandas.DataFrame, which is valuable since no output schema is provided. The annotations already mark the tool as read-only and idempotent, so this extra context meaningfully enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat redundant: the ':return:' line repeats the same phrase as the first line. The URL is useful but not strictly necessary, and the structure mixes Chinese prose with docstring annotations. The IP warning is front-loaded, which is good, but the overall text could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-argument, read-only tool, the description adequately covers purpose, source, the critical IP warning, and return type. It lacks detail about the DataFrame's column structure or data format, but given the simplicity and existing annotations, it is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is trivially 100%. There are no parameter semantics to explain, and the description appropriately focuses on return type instead. The baseline of 4 for zero-parameter tools applies, and the description meets it without needing additional detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as real-time market data for all A-shares from Sina Finance, distinguishing it from similar tools like stock_zh_a_spot_em (East Money) and stock_zh_a_spot_tx (Tencent). However, it lacks an explicit verb (e.g., 'get' or 'return'), presenting the purpose as a noun phrase rather than an action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling alternatives, such as preferring East Money or Tencent sources. The warning about IP blocking from repeated runs is a caution but not a tool-selection guideline, and there are no stated exclusions or prerequisites.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and mutability. The description adds the return type (pandas.DataFrame), the specific source (Tencent), and the scope (all stocks for SH/SZ/BJ), which provides some context beyond annotations. It does not contradict annotations and offers a modest behavioral addition, but no deeper details like rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a clear title line, a source URL, and standard return/rtype annotations. It avoids bloat and front-loads the key information. The URL adds verifiable provenance but is not strictly necessary; still, the overall structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool, the description covers the essential elements: data source, market coverage, data type (real-time), and return format. With annotations covering safety and no output schema present, this is sufficient for an agent to correctly invoke and interpret the result. Minor gaps like specific columns or update frequency remain, but they are not critical for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with zero parameters, so there are no parameter semantics to describe. The description correctly implies no inputs are required, matching the 100% schema coverage. Per rubric, 0 params yields a baseline of 4; no additional param details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states "腾讯证券-沪深京-实时行情数据" (Tencent Securities - SH/SZ/BJ - real-time quotes) and "所有股票的实时行情数据" (real-time data for all stocks), clearly identifying the source (Tencent), market coverage (Shanghai, Shenzhen, Beijing), and data type. This distinguishes it from sibling tools like stock_zh_a_spot_em (Eastmoney) and stock_zh_a_spot (other sources) via the explicit Tencent source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives. The description only explains what it returns (all-stock real-time quotes) but does not mention scenarios, exclusions, or compare with other spot data tools. Unlike the high-scoring example, it names no alternative tools or conditions.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing a safe read-only operation. The description adds context beyond annotations by specifying the data source URL, the meaning of cancellation type codes (100/200/300), and the return type. This enriches behavioral understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact block containing the official title, URL, category codes, and return type. It is front-loaded with the title and avoids excessive verbosity. However, the numeric codes (100/200/300) are cryptic without additional explanation, and the layout is a bit dense, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter, read-only tool, the description covers essential aspects: the data source, the three cancellation categories, and the return type. It does not list the DataFrame columns or any pagination details, but the low complexity and strong annotations make this sufficient. Slightly more detail on output columns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is effectively complete with an empty properties object. The description adds value by specifying the return type (:rtype: pandas.DataFrame), which helps the agent anticipate the output format. Since there are no parameters to explain, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the list of cancelled private fund managers from AMAC, with a specific source URL and return type (pandas.DataFrame). The verb '已注销' (cancelled) and resource '私募基金管理人名单' make the purpose unambiguous. However, it does not explicitly distinguish this from sibling AMAC tools like amac_manager_info, which limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching cancelled manager data through its title and categories (主动注销, 依公告注销, 协会注销), but it does not state when to use this tool versus alternatives or provide exclusions. There is no explicit when-to-use guidance, but the context is clear enough for a user seeking this specific dataset.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that it returns a pandas.DataFrame and identifies the source URL, but does not disclose additional behavioral traits such as pagination or data volume. This is acceptable given annotations, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, containing only the tool name, source URL, and return type. It is not front-loaded in a structured way but avoids redundancy. Slightly more structure could help, but it earns a high score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey what the DataFrame contains. It says '会员机构综合查询' (comprehensive member institution query), which gives a general idea but lacks column names or a summary of fields. For a no-parameter tool, this is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema is empty. The description adds no parameter details because none exist. The baseline of 4 is appropriate as there is nothing to document and the description correctly implies a full dataset fetch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool performs a comprehensive query of member institutions from the AMAC (China Securities Investment Fund Industry Association), with a specific resource and verb. It distinguishes itself from sibling tools like amac_member_sub_info by focusing on the top-level 'member institution' query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage – when one needs AMAC member institution information – and provides the data source URL. However, it does not state when to prefer this over sibling tools or provide any exclusions or alternative recommendations, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds useful behavioral details beyond annotations, such as the return type (pandas.DataFrame), the allowed period values (1, 5, 15, 30, 60), and adjustment choices (qfq, hfq). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a standard docstring format with a clear title, source URL, parameter list, and return type. It is front-loaded with the tool's purpose. The repeated :param/:type pairs are somewhat verbose but each adds value; there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately specifies the return as pandas.DataFrame. It covers all parameters and their choices. It could be more complete by stating that symbol should include an exchange prefix (e.g., 'sz128039') and clarifying the meaning of qfq/hfq, but the current level is sufficient for a simple data retrieval tool with read-only annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains all five parameters: symbol (转债代码), period (choice of 1/5/15/30/60), adjust (choice of '', qfq, hfq), start_date (开始日期), and end_date (结束日期). It also specifies the return type. This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving convertible bond intraday time-sharing quotes from 东方财富网 (East Money). The phrase '分时行情' specifies the data type and differentiates it from siblings like bond_zh_hs_cov_daily or bond_zh_hs_cov_spot, though it lacks an explicit verb such as 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that this is for minute-level data, nor does it suggest using bond_zh_hs_cov_daily for daily data. Given the large number of bond-related sibling tools, the absence of any usage direction is a clear gap.
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 already indicate read-only and idempotent behavior. The description adds a rate-limit warning, but this also appears in the annotations title, so it does not add much beyond what is already structurally provided. No other behavioral traits such as data freshness or pagination are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a docstring with a concise summary, source URL, parameter and return type explanations. It is well-structured and not overly verbose, with each line serving a purpose. The front-loaded one-liner gives immediate clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only states the return is a pandas DataFrame of daily K-line data without specifying columns or date range. The rate-limit warning is helpful, but more detail about the output structure and data scope would make the tool easier to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no property descriptions (0% coverage), so the description must compensate. It explains 'symbol' as a Shanghai/Shenzhen bond code and provides an example (sh010107), which is meaningful guidance for constructing the parameter. This goes beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches historical daily K-line data for Shanghai/Shenzhen bonds from Sina Finance (新浪财经-债券-沪深债券-历史行情数据), with an example symbol and return type. This specific verb-resource-scope combination distinguishes it from sibling tools like bond_zh_hs_spot and bond_zh_hs_cov_daily.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical daily bond data but does not explicitly state when to use this tool over alternatives. It includes a rate-limit warning ('大量抓取容易封 IP'), which is a usage caution, but lacks exclusions or mention of sibling tools for real-time or convertible bond data.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the critical behavioral warning '大量抓取容易封IP' (heavy scraping can get IP banned), which is not captured by annotations. It also clarifies the real-time nature ('当前时刻') and pagination behavior, providing extra context about the tool's execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear title, source URL, parameter docs, and return type. It is not overly verbose, and every line serves a purpose, including the IP ban warning. The docstring formatting adds some clutter but remains readable and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the core purpose, source, return type, and pagination. However, there is no output schema, so the description should detail the DataFrame columns or data structure, which it omits. It also lacks guidance on alternative tools or edge cases, making it only minimally complete for an agent to use it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides parameter names, types, and defaults, with zero description coverage. The description compensates by explicitly defining 'start_page' as 分页起始页 (pagination start page) and 'end_page' as 分页结束页 (pagination end page), adding semantic meaning beyond the schema. However, it does not mention page size or how to determine the page range, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves real-time market data for all Shanghai/Shenzhen bonds from Sina Finance, with a specific source URL and a return type of DataFrame. The phrase '所有沪深债券在当前时刻的实时行情数据' precisely distinguishes it from historical (bond_zh_hs_daily) and convertible bond (bond_zh_hs_cov_spot) siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 among the many bond-related siblings. It only includes a caution about heavy scraping risking IP bans, which is a usage warning but not a selection criterion. No mention of 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety expectations. The description adds the source URL and the return type (pandas.DataFrame), which is useful but minimal. It does not disclose additional behavioral traits like data freshness, pagination, or error handling. Given the annotations cover the key safety profile, this meets the baseline but does not exceed it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the Chinese title, followed by the source URL and return type. Every line adds value: the title states the purpose, the URL provides traceability, and the return type informs output handling. It is somewhat terse and could be better structured with a separate description sentence, but it avoids waste and is appropriately short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the burden of explaining what data the function returns. It states 'public trading market data' and specifies the source, but it does not detail the columns or structure of the DataFrame (e.g., price, volume, date fields). For a simple market data tool, this is minimal but acceptable; additional details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects that with an empty properties object. With no parameters to document, the description has no burden to explain semantics. The baseline is 4 for zero-parameter tools, and the description correctly adds no irrelevant param information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool provides public trading market data for Beijing's carbon emissions trading platform. It names the specific resource (Beijing carbon emissions) and distinguishes it from sibling tools like energy_carbon_gz or energy_carbon_sz by the 'bj' suffix and the explicit '北京市' reference. Though no explicit verb like 'get' is used, the noun phrase '公开交易行情' clearly indicates a data retrieval function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly identifies the tool as specific to Beijing's carbon market, implying it should be used when Beijing carbon trading data is needed. However, it does not explicitly mention alternatives or state when not to use it, such as pointing to other regional carbon tools (e.g., energy_carbon_sz for Shenzhen). With many similar sibling tools, explicit guidance would be valuable, but the Beijing-specific wording gives clear context.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the data source URL and return type but discloses no additional behavioral traits such as date range handling, pagination, or error behavior. It provides marginal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and structured as a docstring. However, it redundantly repeats the title phrase in the first line and the return line, and includes a URL that could be seen as extra. It is not excessively verbose, but the duplication could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only states the return type is pandas.DataFrame without describing columns or data structure. While the title implies historical NAV data, an agent would benefit from knowing the exact columns or any nuances like date inclusivity. The description is adequate but not exhaustive for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the docstring fully compensates by defining all three parameters (fund, start_date, end_date). It adds meaning, especially for 'fund' by referencing how to obtain the code, but the date parameters are only described as 'start/end time' without specifying format (though defaults imply YYYYMMDD).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fetching historical NAV details for on-exchange trading funds from Eastmoney. It specifies the resource ('场内交易基金-历史净值明细') and uses a specific verb ('获取' implied), distinguishing it from siblings like spot 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite by noting the fund code can be obtained via fund_etf_fund_daily_em, but it does not explicitly state when to use this tool versus alternatives (e.g., fund_etf_hist_em for price data). Usage context is implied, not explicitly articulated.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that date defaults to the current trading day, accepts multiple date formats, and returns a pandas DataFrame in unified format, adding value beyond annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a standard Python docstring format, listing parameters, types, and return type without extraneous text. It is efficient and well-structured, though the first line duplicates the annotation title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool with no output schema, the description covers parameter semantics, defaults, and return type sufficiently. It lacks detail on the DataFrame columns, but that is not essential given the tool's simplicity; however, it does not clarify when to use this generic tool versus exchange-specific siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema only reveals two string parameters with defaults; the description enriches by explaining valid date formats (YYYY-MM-DD, YYYYMMDD, or datetime.date), default behavior (current trading day), and market code mappings (CFFEX-中金所, etc.). This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '期货交易所结算参数' and includes ':return: 结算参数数据（统一格式）', making clear it returns futures exchange settlement parameters for a given date and market. However, it lacks an explicit imperative verb like 'get' or 'retrieve', and does not differentiate from sibling tools like futures_settle_cffex.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter details but no guidance on when to use this tool versus the exchange-specific siblings (futures_settle_cffex, futures_settle_ine, etc.). There is no mention of alternatives or exclusions, leaving the agent to infer the tool's role.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds behavioral context by stating the default date is the current trading day and that the return type is a pandas.DataFrame, which goes beyond annotations. No contradictions with the annotations were found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a docstring with title, URL, and param/return sections. The URL adds reference value but is not essential for invocation. No redundant information, and the content is front-loaded. The Chinese language is appropriate for the domain, and every sentence contributes to understanding the tool's use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter, the description covers the parameter semantics and return type (pandas.DataFrame) sufficiently. There is no output schema, but the description indicates the return shape. It could mention the specific columns or fields in the settlement data, but for a simple date-query tool, the information is fairly complete. The lack of explicit sibling differentiation slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'date' string parameter with a default and no description (0% schema coverage). The description compensates fully by specifying accepted formats (YYYY-MM-DD, YYYYMMDD, or datetime.date), the default (current trading day), and the parameter type. This is thorough and essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's scope clearly: Shanghai Futures Exchange settlement parameters, with a return of 结算参数数据 (settlement parameter data). While it lacks an explicit verb like 'get' or 'retrieve', the docstring's :return: line implies data retrieval. The exchange name distinguishes it from sibling tools for other exchanges (e.g., futures_settle_ine, futures_settle_cffex).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exchange-specific siblings. The description only documents the date parameter's default behavior and formats, but does not mention exclusions or alternatives. For a tool in a family of similar exchange-settlement functions, explicit usage distinctions would be valuable.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the data source URL and return type (dict), but does not disclose behaviors like handling of non-trading days, potential delays, or the structure of the returned data. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, using a standard docstring format with :param, :type, :return, and :rtype lines. It efficiently conveys the source URL, parameter details, and return type. However, it is entirely in Chinese, which slightly reduces readability for English-speaking agents, but it is still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter, read-only tool with no output schema. The description covers the data source, parameter format, and return type, which is adequate for selecting and invoking the tool. However, it lacks detail on the structure of the returned dict, which would be helpful for processing the result. Overall, it is complete enough but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well by explaining ':param date: 交易日' (trading day) with an example format '20200702'. This adds meaning beyond the schema's type and default fields, clearly defining the required date format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's title '上海期货交易所指定交割仓库期货仓单日报' clearly identifies the tool as retrieving the SHFE designated delivery warehouse receipts daily report. The :return: line specifies it returns the warehouse receipt daily data for the specified date, which is a specific verb+resource+scope statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SHFE warehouse receipt data by date, but does not explicitly state when to use it versus alternative tools like futures_warehouse_receipt_czce or futures_warehouse_receipt_dce. No exclusions or alternative recommendations are provided, so guidelines are merely implied.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context: the publication schedule (only on the last trading day) and the return type ('pandas.Series'). It also includes the source URL, which provides traceability. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title line, a source URL, and a structured docstring. It is front-loaded with the key resource name and avoids redundant fluff. The docstring format is well-organized and easy to parse, though it could be slightly more concise by omitting the URL.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers the essential aspects: what data is returned (inventory weekly report), when it is available (last trading day), and the return type (pandas.Series). Combined with the annotations, the context is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter `date` with no description (schema coverage 0%). The description compensates with a docstring: ':param date: 交易日' (trading day) and clarifies that data is only published on the last trading day. The default value '20240419' also implies the expected format (YYYYMMDD), adding practical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear resource name: '金十财经-上海期货交易所指定交割仓库库存周报' (Jin10 Finance - SHFE designated delivery warehouse inventory weekly report), which identifies the specific data being retrieved. Though it lacks an explicit verb like 'get' or 'list', the docstring and URL make the tool's function unambiguous. It is reasonably distinct from siblings like futures_shfe_warehouse_receipt, but does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage constraint: '库存周报只在每周的最后一个交易日公布数据' (the weekly report is only published on the last trading day of the week), guiding when data is available. However, it does not discuss alternatives or provide a 'when not to use' comparison with other futures tools, leaving the usage context partially implicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only profile. The description adds meaningful behavioral context beyond those hints: the 20200720 data cutoff caused by exchange website issues, the limitation that the exchange only publishes underlying contract rankings, and the daily 16:30 update cadence. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence followed by caveats, parameter documentation, and a structured return-format table. The return column block is lengthy but justified since no output schema exists to carry that information. Sections are logically ordered and each part contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read-only tool with no output schema and 0% schema coverage, the description is highly complete: it covers purpose, data availability constraints, scope limitations, parameter formats and defaults, return type, and all 11 return columns. The main gap is the internal inconsistency between the 20200720 data cutoff and the 20060104 start date mentioned in the vars_list documentation, which leaves uncertainty about actual data availability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining both parameters. It documents date formats (YYYY-MM-DD, YYYYMMDD, datetime.date object), the default 'today' behavior, and vars_list semantics (a list of varieties, empty = all commodities). However, it does not enumerate which variety codes are valid for DCE, and its examples (RB, AL) are Shanghai Futures Exchange products, which could mislead users selecting parameters for this DCE-focused tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: DCE (Dalian Commodity Exchange) top 20 member position ranking details (大连商品交易所前 20 会员持仓排名数据明细). It adds a distinguishing note that the exchange only publishes underlying contract rankings. However, it does not explicitly differentiate from closely related siblings like futures_dce_position_rank or get_cffex_rank_table, relying only on the exchange name mentioned in both the tool name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides helpful usage context: accepted date formats, default 'today' behavior, empty vars_list meaning all commodities, and the ~16:30 daily data update schedule. However, it never states when to prefer this tool over alternatives like get_cffex_rank_table, get_shfe_rank_table, or futures_dce_position_rank, and the data availability guidance is internally inconsistent—the header says data only exists after 20200720, while the vars_list parameter says data starts from 20060104.
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?
Annotations already declare read-only, idempotent, non-destructive. The description adds behavioral details: returns DataFrame or None, defaults to current trading day, and lists source URLs. It doesn't contradict annotations and provides useful context about return variability and default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a structured docstring with title, product context, source URLs, params, and return info. It is reasonably concise, though the URLs and product listing dates might be extraneous for invocation. Front-loaded with the title, making the tool purpose immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool, the description covers purpose, parameter formats, default, and return type. It doesn't specify DataFrame columns, but '量价数据' implies typical OHLCV data. Without an output schema, this is adequate but could be richer by noting what columns or instruments are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (date). The description compensates for 0% schema coverage by explaining accepted formats (YYYY-MM-DD/YYYYMMDD/datetime.date), default value semantics (current trading day), and type flexibility (str or datetime.date). This goes far beyond the schema's simple `string` type and gives the agent everything needed to populate the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as retrieving Shanghai International Energy Exchange daily frequency price-volume data and lists the specific products (crude oil, TSR 20 rubber) with listing dates. However, it lacks an explicit verb in the description itself (action only in the tool name), and doesn't explicitly contrast with similar exchange daily 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the exchange and data type imply usage for INE daily data, there is no mention of when not to use it or how it differs from get_shfe_daily, futures_settle_ine, etc. In a large sibling set like this, the lack of differentiation is a gap.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context: the data source URLs, the limitation that only per-product rankings are available (no product totals), the historical start date, and the update schedule. It also details the return fields. This goes beyond the annotations and helps the agent understand what to expect, though it does not cover potential pagination or error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: title, source URLs, note, data availability/update time, parameter documentation, and a detailed return field table. Each section serves a purpose and the critical note about no total ranking is front-loaded among the notes. While it is long, the field table is informative and the structure is logical. It is not overly repetitive and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description is quite complete: it gives source URLs, data history, update timing, a key limitation, parameter docs, and a field-by-field return description. The primary gap is the lack of the top-level structure of the returned dict (e.g., how the fields are organized into keys), and it does not clarify that vars_list must be restricted to SHFE products despite the schema default containing non-SHFE codes. Still, the level of detail is high and covers most context an agent would need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden for parameters. It explains 'date' as the trading day (str) and 'vars_list' as contract varieties like RB and AL, noting that an empty list returns all commodities. This adds meaningful semantics beyond the bare schema. The format of date (YYYYMMDD) is implied by the return field description. The explanation is useful but could be more explicit about the valid codes for SHFE specifically, especially given the schema's default list includes non-SHFE contracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the Chinese title '上海期货交易所会员成交及持仓排名表' which clearly identifies the tool as retrieving Shanghai Futures Exchange member volume and position rankings. The note that the exchange only publishes within-product rankings and not total product rankings helps distinguish this tool from siblings like get_rank_sum or other exchange-specific rank tables. The purpose is clear, though it relies on the tool name for the verb rather than having an explicit action word 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual guidance: it is specific to SHFE, data starts from 20020107, and updates around 16:30 each trading day. The note about no overall product rankings is an exclusion, but there is no explicit mention of when to use this tool versus alternatives such as get_cffex_rank_table or get_dce_rank_table. Usage is implied by the SHFE name and the note, but the description does not name alternatives or state clear when-to-use/when-not-to-use scenarios.
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?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: the exact date range, source URLs, return type (pandas.Series), and current value unit (%). This helps set expectations for the output and data provenance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose and date range. It also includes source URLs and return documentation, which adds some clutter but is still concise and information-dense. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, read-only, clear data source), the description is complete enough for an agent to select and invoke it correctly. It specifies the data range, source, and output format. The lack of an output schema is mitigated by the explicit return type and unit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The description provides return type and value details, which compensates for the lack of an output schema. A baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Brazil interest rate decision report with a specific date range (20080201 to present). It is distinguishable from sibling macro_bank_* tools by the country in its name, but it lacks an explicit verb like 'get' or 'fetch'. The purpose is nonetheless 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving Brazil's interest rate decision data but does not explicitly state when to use this tool versus alternatives. Given the clear country-specific name and the structure of sibling tools, an agent can infer when it is appropriate, but no direct comparison or exclusion is provided.
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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by specifying the data range (19990101 to present), the return type (pandas.Series), and providing source URLs, which helps the agent understand what data it will receive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes essential information: title, data range, source URLs, return type, and unit. It is slightly unstructured with long URLs, but every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides sufficient context by specifying the data range, return type, and percentage unit. It does not mention update frequency, but this is a minor gap for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter behavior. The baseline score of 4 applies, as there are no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the tool as the 'European Central Bank decision report' and specifies the return value as the current value in percent, making the purpose clear. It distinguishes itself from sibling macro_bank_* interest rate tools by explicitly mentioning the Euro/ECB, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for European Central Bank interest rate decision data through the name and content, but does not explicitly state when to choose this tool over the many other macro_bank_* interest rate tools. No exclusions 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds the return type (pandas.DataFrame) and the metric, but does not disclose additional behavioral traits such as data range, update frequency, or potential missing values. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the most critical information: the source, the specific data indicator, the URL, and the return type. Every sentence is informational and not redundant. It appropriately uses a structured docstring format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data fetch, the description is reasonably complete: it names the data source, the metric, and the return type. However, with no output schema, it does not describe the columns or time-frequency of the DataFrame, which would be useful for an agent expecting a specific structure. Given the simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema confirms no required inputs, and the description correctly implies a no-argument call. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 东方财富-经济数据一览-中国香港-消费者物价指数年率 (Eastmoney Economic Data Overview - Hong Kong - CPI YoY). It specifies the exact data item and source URL. The name and description together distinguish it from other HK macro tools by explicitly stating the year-on-year ratio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as macro_china_hk_cpi or other HK economic indicators. There is no explicit context for selection, only an implicit 'this is what it provides'.
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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds useful context: the data range, source URLs from Jin10, and the pandas.DataFrame return type. No behavioral contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the core purpose. It includes supplementary source URLs and return type, though the first sentence largely duplicates the annotation title and the URLs are not strictly necessary for invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter data-retrieval tool, the description provides the data set, date range, source, and return type, while annotations cover safety semantics. It does not enumerate the DataFrame columns, but this is not a critical gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so the schema already fully defines the input. Description adds no parameter details, which is appropriate for this zero-parameter tool; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning China's industrial value-added year-over-year report (中国规模以上工业增加值年率报告) with a specific data range from 19900301 to present. It distinguishes itself from sibling macro indicators by naming the exact metric, though it lacks an explicit verb like 'retrieve' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the data description: an agent would use this when needing China's industrial production YoY report. However, there is no explicit guidance on when to choose this over sibling macro_china_* tools or any mention of alternatives/exclusions.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: the data range, the return type (pandas.Series), and that it returns the 'current value' (今值), plus source URLs for verification. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by source URLs and return type. The URLs are somewhat extraneous for invocation but do not bloat the description significantly. The Python docstring style (:return:, :rtype:) is structured and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter data retrieval tool, the description provides sufficient context: data range, return type, and source URLs. There is no output schema, but the described return type (pandas.Series) and 'current value' clarify the expected output. No critical information is missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input surface (coverage 100%). With no parameters to explain, the baseline of 4 applies, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the Eurozone services PMI final report with a specific data range (from 20080222 to present), distinguishing it from sibling PMI tools by region and sector. However, it lacks an explicit verb like 'fetch' or 'get', relying on the noun phrase '报告' (report) to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the resource name and data range, but provides no explicit guidance on when to choose this tool over alternatives like macro_euro_manufacturing_pmi or macro_usa_services_pmi. There are no exclusions or contextual hints beyond the self-explanatory title.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds meaningful context beyond annotations by specifying the return type (pandas.DataFrame), the source URL, and the exact data content (实际零售销售月率). This helps the agent understand output format and provenance. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of a title, source URL, return description, and return type. All lines contribute useful information. It is front-loaded with the key purpose. However, '实际零售销售月率' appears twice (in the title and return), which is a slight redundancy, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple no-parameter data retrieval tool with no output schema. The description provides the source, return type, and data description, which is sufficient for an agent to understand what it returns. It does not explain the data frequency or interpretation of '月率', but that is largely carried by the name and context. For its simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (trivially). With 0 params, the baseline for this dimension is 4. The description does not need to explain parameters, and it adds value by stating the return type, which is the only meaningful semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Germany's actual retail sales monthly rate from Eastmoney Data Center, with a specific URL and return type. It distinguishes from sibling tools like macro_germany_retail_sale_yearly by explicitly naming the monthly rate (月率). However, it lacks an explicit verb like 'fetch' or 'get', relying on the noun phrase to imply retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives like macro_euro_retail_sales_mom or macro_germany_retail_sale_yearly. The context is implied by the name and description (Germany, monthly retail sales), but without clear exclusions or explicit when-to-use instructions, it falls short of a 4.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type (pandas DataFrame) but does not disclose any additional behavioral traits such as pagination, rate limits, or data freshness. It is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loads the essential information: source, metric, URL, return value. It is slightly redundant in repeating the metric name in the return line, but overall every sentence serves a purpose and the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature and no parameters, the description is adequate. However, there is no output schema, so the description should more explicitly describe the DataFrame's structure (e.g., columns or index). It only names the metric without specifying the data shape or historical range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the parameter schema is trivially complete. With no parameters, the description need not elaborate on parameter meaning. The baseline of 4 applies because no parameter information is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (东方财富/Data Center), the geographic and metric scope (Germany real retail sales annual rate), and the return type (pandas DataFrame). It distinguishes from sibling tools like macro_germany_retail_sale_monthly by explicitly specifying 'yearly'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving Germany's real retail sales annual rate from Eastmoney, but provides no explicit guidance on when to use this tool versus alternatives (e.g., monthly data, other countries). No exclusions or alternative recommendations are stated.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds a return type (pandas.DataFrame) and source URL, but no further behavioral details like data frequency, date range, or potential caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a title line, a URL, and a return type annotation. Every line earns its place, and the most important info (metric and source) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-param tool with no output schema, the description provides the essential context: the specific economic indicator (UK core CPI monthly rate), the source (East Money with URL), and the return format (pandas.DataFrame). It lacks details like units or column names, but these are not critical for basic selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. Schema coverage is 100% (empty object) and the baseline for 0 params is 4; the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving UK core consumer price index monthly rate data from East Money (东方财富). It specifies the exact metric (核心消费者物价指数月率) and includes the source URL, effectively distinguishing it from siblings like macro_uk_cpi_monthly by the 'core' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 macro_uk_core_cpi_yearly or macro_uk_cpi_monthly. The description simply names the metric and source, leaving the agent to infer usage context from the tool name alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds the return type (pandas.DataFrame) and source URL, which are useful but do not go beyond the annotations' safety traits. No additional behavioral context (e.g., update frequency, data completeness) is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines with the data provider, specific indicator, and source URL, plus a clear return type. Every element is purposeful, no filler or repeated information from the tool name or annotations. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter data retrieval tool with no output schema, the description is sufficiently complete: it states the source, the exact indicator, and the return format. The annotations cover safety, so no additional context is critical. A slight gap is the lack of any mention of time range or currency, but these are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object with 100% coverage (vacuously). There is nothing to document, and the baseline for 0 params is 4. The description does not need to add parameter semantics, but it also does not introduce any confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (UK Halifax house price index monthly rate from Eastmoney economic data) and explicitly states what is returned (a pandas DataFrame of the monthly rate). It is distinct from siblings like macro_uk_halifax_yearly by specifying '月率' (monthly rate), so an agent can differentiate it without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as macro_uk_halifax_yearly, macro_uk_rightmove_monthly, or other UK economic indicators. The agent is left to infer usage solely from the name and the generic 'economic data' label.
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 already declare the tool as read-only, idempotent, and non-destructive, so the description does not need to restate that. It adds useful context by mentioning the data range, return type, and source URL, but does not disclose any subtle behaviors like rate limits or data quirks. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two lines) but contains redundancy: the first sentence and the return-type line repeat the same report name. It is front-loaded with the core information, but could be more streamlined by merging the redundant parts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter data retrieval tool with annotations, the description provides the essential context: data range, source URL, and return type. However, it lacks detail on the actual columns or contents of the DataFrame (e.g., fields like currency, open interest, positions), which could be important for an agent selecting this tool. Given the absence of an output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not elaborate on parameter semantics. The schema is empty, and the description provides no additional parameter context, which is acceptable given there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a CFTC foreign exchange non-commercial holdings report, specifying the data range (19830107-present) and source URL. This distinguishes it from sibling tools like macro_usa_cftc_c_holding or merchant_currency_holding, which cover different report categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what data it returns (a pandas DataFrame of CFTC FX non-commercial holdings), but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. The context is sufficient for an agent to infer its use, but not explicitly stated.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the source URL and return type, which is helpful but doesn't disclose additional behavioral traits such as rate limits, data freshness, or output granularity (e.g., includes both call and put quotes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. It includes the source URL, parameter explanation, and return type in four lines. The :param/:type/:return notation adds structure, though the URL line could be seen as extra; overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fairly complete: it states the data source, how to find valid symbols, and the return type. It doesn't mention if the result includes both call and put rows or any data limitations, but it's adequate for a real-time quote fetcher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains that 'symbol' is the contract code and references a specific list function to discover valid values. This is good guidance, though it doesn't provide a concrete example beyond the schema default 'ho2303'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: fetching real-time quotes for a specified contract of the CFFEX SSE 50 Index options from Sina Finance. It distinguishes from siblings like option_cffex_sz50_daily_sina (daily) and option_cffex_sz50_list_sina (contract list) by explicitly saying '实时行情'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on how to obtain the required symbol parameter by directing users to ak.option_cffex_sz300_list_sina(). It implies when to use this tool (for real-time spot quotes) without explicitly naming alternatives, but this is sufficient for a straightforward data retrieval function.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the return type (pandas.DataFrame) and parameter meaning, but provides no extra context about data freshness, limitations, or behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: title, source URL, and docstring parameters. Each line contributes value, and there is no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and rich annotations, the description covers the core aspects: what the tool returns and the parameter meaning. It could be more complete by listing example board names or DataFrame columns, but these are minor omissions for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'symbol' parameter, but the description explains it accepts a board name or code, adding essential meaning. It does not provide format examples, but the default value and type are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as retrieving '板块成份' (board constituents) for EastMoney Shanghai/Shenzhen concept boards, with a source URL and Python-style docstring. This distinguishes it from sibling tools like spot data or historical data retrievers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools, exclusions, or prerequisites, leaving the usage context to be inferred purely from the tool name.
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 already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds only some context like the return type (DataFrame) and adjustment choices. It does not disclose potential quirks like date format requirements or behavior on invalid inputs, but the existing annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring with a clear title, URL, and parameter list. However, it contains a redundant and incorrect line for 'period' that duplicates 'symbol', and the parameter lines are not perfectly ordered, reducing structural elegance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple historical data tool with annotations and 5 parameters, the description covers the resource, source, parameters, and return type. It does not list the DataFrame columns or explicitly state the date format, but defaults and context make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for all 5 parameters. It provides meanings for symbol, period, start_date, end_date, and adjust choices, though there is a typo where 'period' is incorrectly described as '板块名称' (same as symbol), which slightly undermines clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches historical quotes for Shanghai/Shenzhen concept boards from Eastmoney, as shown in the title and first line. It distinguishes from sibling tools like spot or minute-level board tools because it specifically handles historical daily/weekly/monthly data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical data via the title and parameter choices, but does not explicitly contrast with alternatives like spot or intraday tools. It lacks any when-to-use or when-not-to-use guidance 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?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that the return type is a pandas DataFrame, that the symbol must include a market identifier (e.g., SZ000013), and provides a source URL, giving beyond-annotation context about the expected input format. It does not conflict with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized as a typical docstring with title, URL, parameters, return, and rtype. The URL is long but provides source context; overall it's efficient and front-loaded with the identifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, non-destructive data retrieval tool, the description is fairly complete: it names the resource, parameter format, return type, and source. It doesn't elaborate on data columns or error conditions, but given the output is a DataFrame and annotations are present, the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by defining the symbol parameter as a delisted stock code with market identifier and showing the default in the schema. The format guidance (e.g., SZ prefix) is clearly stated, though it doesn't enumerate all possible market prefixes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving cash flow statements for delisted stocks by reporting period from Eastmoney, with a specific URL and resource hierarchy. It distinguishes from sibling tools like stock_cash_flow_sheet_by_report_em by the 'delisted' qualifier, though it lacks an explicit verb and relies on a noun phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for delisted stocks through the name and symbol documentation, but offers no explicit guidance on when to choose this over the many sibling cash flow tools (e.g., quarterly/yearly variants). No exclusions or alternative recommendations 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the data source (East Money) and return type (pandas.DataFrame) but does not disclose additional behaviors such as latency, data freshness, or any caveats. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a title, URL, parameter specification, and return type. It is compact and front-loaded with the tool's identity, though the line breaks and repeated info (title and URL) slightly reduce precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description indicates the return is a pandas.DataFrame but does not detail columns or contents beyond '盘口异动'. However, the tool has a single well-documented parameter and strong annotations, making it reasonably complete for a simple retrieval query. The lack of column details is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists a 'symbol' string with a default, but the description provides an exhaustive list of 22 valid choices and explicitly states the parameter's meaning and type. This fully compensates for the schema's lack of enum or description, giving the agent complete information to pass a valid parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 盘口异动 (market changes) data from East Money's 行情中心, with a URL and a specific list of supported symbols. The name stock_changes_em and title make the resource clear, though it doesn't explicitly differentiate from sibling stock data tools beyond the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing valid symbol choices (e.g., '大笔买入', '封涨停板'), but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The purpose is clear enough that an agent would infer when to use it, but there is no direct comparison with sibling tools.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: heavy usage may get the IP banned, with a recommended retry delay. It also discloses the return type as pandas.DataFrame. This enriches the behavioral profile meaningfully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes only relevant details: source, resource, data type, return format, and a critical usage warning. The URL and title are somewhat redundant with the name and description, but they do not significantly bloat the text. The structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with strong annotations, the description covers the core essentials: what it returns (real-time index quotes), from where (Sina Finance), and the return type (DataFrame). It also adds operational context about IP bans. There is no output schema, so the return type hint is useful. The only missing element is explicit differentiation from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds semantic meaning by stating '所有指数' (all indices), making clear the tool returns data for all HK indices without filtering. No parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns real-time market data ('实时行情数据') for all Hong Kong stock indices from Sina Finance ('新浪财经'). The noun and scope are specific, and the source is named. However, it does not explicitly distinguish this from the sibling tool stock_hk_index_spot_em, which likely serves the same purpose from a different data provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an operational guideline: mass requests can lead to IP bans, and users should wait 10 minutes if banned. It does not, however, provide guidance on when to choose this tool over alternatives like stock_hk_index_spot_em, nor does it mention any prerequisites or context for typical use.
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 already provide readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the data source and a note that data starts from 2010, which is useful context beyond the annotations. However, it does not disclose any additional behavioral traits such as rate limits, pagination, or data granularity, and there is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear sections for param and return, making it easy to parse. It includes a URL that may be extraneous but is not overly verbose. It is relatively front-loaded with the source path, though it lacks a single crisp one-liner summarizing the action. Overall, every sentence earns its place except the URL could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one simple parameter and the annotations cover safety, the description is mostly complete: it states the data source, parameter choices, and return type (pandas.DataFrame). No output schema exists, so the return type disclosure is important. The phrase '从 2010 开始' is somewhat ambiguous (whether it refers to the start date of data or a parameter constraint), and the description does not detail the DataFrame's columns or other edge cases, but for a simple retrieval tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the symbol parameter and no enum values. The description fully compensates by enumerating the exact allowed choices: 单独控制, 实际控制人, 一致行动人, 家族控制, 全部. It also hints at the data period starting 2010. This is essential information for correctly selecting and invoking the tool, making the description highly effective for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: 实际控制人持股变动 (actual controller shareholding changes) from 巨潮资讯 cninfo data center thematic statistics. It specifies the return type as pandas.DataFrame. However, it uses a noun phrase rather than an explicit imperative verb like 'get' or 'query', and does not explicitly distinguish itself from sibling tools such as stock_hold_change_cninfo, though the subject matter is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about the data source and topic, implying it should be used when actual controller shareholding changes are needed. It also lists valid symbol choices. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites, leaving usage guidance largely implicit.
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 already declare this as read-only, idempotent, and non-destructive. The description adds the source URL and return type, but does not disclose additional behavioral aspects like rate limits, pagination, data freshness, or that it fetches from an external website. It does clarify the ranking is specifically for '增持' (increase) which is a meaningful filter, but overall it adds minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with a clear title, source URL, and parameter documentation. It is not overly long, though the title is redundant with the annotations and the ':return:' line simply restates the title. Overall, information density is good and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter ranking tool, the description provides the necessary parameter choices, source URL, and return type. It does not explain the columns of the returned DataFrame or how the 'indicator' values map to time windows, but these are fairly intuitive. Given no output schema exists, the description is mostly sufficient for an agent to invoke the tool and interpret the result as a ranked DataFrame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no enums and 0% description coverage, but the docstring fully enumerates valid choices for both parameters: symbol (industry/concept/region) and indicator (今日/3日/5日/10日/1月/1季/1年). This is essential for correct invocation and fully compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching a ranking of boards (industry/concept/region) by northbound capital increase from East Money Data Center. The title names the exact resource and the param choices further specify the scope, distinguishing it from sibling HSGT tools that cover different datasets like fund flow or individual holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other HSGT or ranking tools. It simply lists the data source and parameter options, without mentioning alternatives, prerequisites, or exclusions. An agent is left to infer usage from the title alone.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it queries the specific CNInfo p_stock2110 endpoint and returns a pandas DataFrame, but it does not describe authentication, rate limits, pagination, or the exact structure of the returned 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with one line for purpose, a source URL, and parameter/return definitions. It is not overly long, though the first line duplicates the annotation title. The information is front-loaded with the main purpose in the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return values. It states the return type (pandas.DataFrame) and content (行业归属的变动情况), but does not specify the DataFrame columns or any additional behavior such as date boundaries or error conditions. Given the simplicity of the tool and read-only annotations, the description is adequate but leaves some ambiguity about the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only names and defaults for the three parameters, with 0% description coverage. The description compensates by defining each parameter: symbol (股票代码), start_date (开始变动日期), and end_date (结束变动日期), making their purpose clear. It does not state the date format explicitly, but the defaults (e.g., 20220713) imply YYYYMMDD.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '查询 p_stock2110 接口' (query the p_stock2110 interface) and describes the resource as '上市公司行业归属的变动情况' (changes in industry attribution of listed companies). This clearly identifies the tool as a query for industry attribution changes from CNInfo, distinguishing it from sibling tools like stock_industry_category_cninfo and stock_industry_pe_ratio_cninfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that this tool queries industry changes for a stock over a date range, but it does not mention any alternative tools, when-not-to-use conditions, or prerequisites. The usage is implied by the parameter definitions but not explicitly guided.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type (pandas DataFrame) but does not disclose other behavioral traits such as pagination, data freshness, or rate limits. This is acceptable baseline given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short lines, front-loaded with the purpose, followed by the source URL and return type. Every line adds practical value—the source URL aids verification, and the return type tells the agent what to expect—without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description covers the essentials: what it returns (stock list), in what format (pandas DataFrame), and the source URL. However, the function name implies the list contains names and codes, which is not explicitly stated in the description. This is a minor gap given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty properties). Since there are no parameters to explain, the description is not required to add parameter detail. The baseline of 4 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '北京证券交易所-股票列表' (Beijing Stock Exchange stock list), identifying both the specific resource and the operation. The URL provides the data source, and the exchange name distinguishes it from sibling tools like stock_info_sh_name_code and stock_info_sz_name_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no exclusions, and no context beyond the raw fact that it returns a stock list. With many sibling stock-info tools, explicit use-case guidance would be valuable but is absent.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that it returns a pandas.DataFrame and specifies the data source, but it does not disclose additional behavioral traits such as data coverage gaps, delisted-stock behavior, or rate limits. It provides modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured: a title line, a source URL, then a concise docstring with param/return sections. It avoids unnecessary prose and is easy to scan, though the title line partially duplicates the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description is adequate: it specifies the data source, the period, and the return type (DataFrame). However, there is no output schema and the description does not elaborate on what columns or data fields the DataFrame contains, leaving the agent to infer the structure from domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly documents the 'symbol' parameter: '股票代码; 带市场标识' (stock code with market identifier) and type str. The URL example 'code=sh600519' illustrates the expected format (market-prefixed code), giving the agent concrete guidance for parameter construction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves the annual income statement (利润表-按年度) for stocks from Eastmoney, with a provided URL. It distinguishes from sibling tools like stock_profit_sheet_by_quarterly_em and stock_profit_sheet_by_report_em by specifying the '按年度' (annual) timeframe, making the resource and period 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly discuss when to use this tool versus alternatives (e.g., quarterly or report versions). The name and the '按年度' phrasing imply that it is for annual data, but no direct guidance is given about when an agent should prefer this over sibling profit-sheet tools.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the specific data provenance (Eastmoney website URL) and return type (pandas.DataFrame), which provides useful behavioral context beyond the annotations. It doesn't mention rate limits or potential delays, but for a simple read-only quote tool, the core behavior is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a source URL and return type. It earns its place with a clear source citation and type hint. It could be slightly more structured with explicit labels, but it's efficient and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, no output schema, and simple read-only behavior, the description provides sufficient completeness: it identifies the market, source, and return type. It doesn't describe the exact DataFrame columns or size, but for a real-time spot quote tool with clear sibling context, this is adequate. The source URL adds trust and traceability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage, meaning there are no parameters to document. The baseline for 0 params is 4, and the description does not introduce any parameter-related confusion. It explains the return type, which is relevant context for invocation, though not strictly parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves real-time quotes for Shanghai A-shares from Eastmoney, with a source URL. It specifies the market (沪 A 股) and the action (实时行情), which distinguishes it from similar tools like stock_sz_a_spot_em (Shenzhen) and stock_kc_a_spot_em (STAR). However, it lacks explicit detail on the exact data columns or scope, and the name is somewhat cryptic without 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the data source and market (Shanghai A-shares), but it provides no explicit guidance on when to choose this tool over alternatives like stock_zh_a_spot_em or stock_sz_a_spot_em. The URL and market designation give context, but there is no when-to-use or when-not-to-use guidance, only implied 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame), but does not disclose additional behaviors such as pagination or rate limits. This adds some value beyond annotations but is not rich in 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with a clear docstring structure. It includes a useful data source URL and parameter/return documentation. It could be slightly tighter, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description is nearly complete: it states purpose, parameter values, return type, and source. It does not list the DataFrame columns, but given the low complexity and lack of output schema, this is an acceptable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' as a string with a default, with 0% description coverage. The description compensates fully by enumerating all valid values ('全部股票', '沪市主板', '科创板', '深市主板', '创业板', '北交所') and their meaning, providing complete parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '新股申购与中签查询' (new stock subscription and winning results query), with a specific verb '查询' and resource. The URL and parameter choices further clarify the scope. It distinguishes from sibling tools by focusing on subscription and lottery results rather than other IPO stages like review or declaration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 defines what the tool does and lists the symbol parameter choices. No mention of exclusions or related tools (e.g., stock_ipo_review, stock_xgsr_ths), leaving the agent to infer usage context.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: the risk of IP banning under high request volumes, a recommended retry delay, and the return type (pandas.DataFrame). This significantly informs agent expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and includes only relevant technical details: source path, URL, a caution about IP bans, and return type. It is well-structured as a docstring, though the Chinese title and URL add some redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description covers the essential aspects: data source (Sina), scope (all A-share indices), return type (DataFrame), and a critical operational warning (IP banning). It is sufficient for an agent to decide whether to use it, though explicit column details are not provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. With no parameters to document, the description need not explain any input semantics. The baseline for 0 params is 4, and there is no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning real-time market data for all A-share indices from Sina Finance ("所有指数的实时行情数据"). The source and scope are explicit, but it lacks a verb like 'get' or 'fetch' and does not differentiate from sibling tools such as stock_zh_index_spot_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a practical warning about IP bans from heavy scraping and suggests retrying after 10 minutes, which implies usage frequency constraints. However, it does not explicitly state when to choose this tool over alternatives (e.g., stock_zh_index_spot_em), nor does it mention exclusion conditions.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds a valuable behavioral warning that frequent scraping can lead to IP blocking, which is useful context beyond the annotations. It also provides the data source URL, adding transparency about origin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the key purpose. The URL and warning are useful additions without excessive verbosity, though the mix of Chinese text and the :return:/:rtype: lines could be more structured for an English-speaking agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool, the description covers the essential aspects: source (Sina Finance), data type (real-time KCB quotes), return format (DataFrame), and a rate-limit warning. Without an output schema, it does not list columns, but this is acceptable for a broad market snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, confirmed by both the input schema and the description. With no parameters to explain, the baseline of 4 applies; the description appropriately focuses on the data returned rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as '新浪财经-科创板实时行情数据' (Sina Finance STAR Market real-time quotes) and the :return: line confirms it returns a pandas DataFrame of that data. It distinguishes from siblings by specifying the Sina Finance source and KCB spot scope, though it lacks an explicit verb like 'fetches'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining STAR Market real-time quotes from Sina Finance, and the warning '大量抓取容易封IP' suggests cautious use. However, it does not explicitly state when to use this tool over alternatives like stock_kc_a_spot_em (which provides similar data from Eastmoney), nor any exclusion criteria.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context about performance (hourly period downloads slowly due to large data size), the data source URL, and return format, which goes beyond the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat dense and mixes prose with docstring-style param/type/return blocks, but is generally clear. It includes a URL and period guidance that are useful, though the formatting is not ideal for quick scanning and is slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains the return type (pandas.DataFrame) and the date range semantics. It covers all 4 parameters, data source, and performance caveats. For a read-only, idempotent tool, this is reasonably complete, though it doesn't specify units or exact columns of the returned DataFrame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meanings. It explains every parameter (city, period, start_date, end_date) with types and concrete examples (e.g., '20190327'), and even clarifies the return type. Despite lacking formal schema descriptions, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a historical air quality data retrieval tool from 真气网 (zq12369.com), with a specific resource (air quality by city, period, and date range) and a defined return type (pandas.DataFrame). It's distinguishable from siblings like air_quality_hebei or air_quality_rank by focusing on historical time-series data for any city, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions for all parameters, including examples and guidance on period selection (e.g., 'hour' downloads slower due to data volume). It references using ak.air_city_table() to get the city list, but does not explicitly state when to use this tool versus alternatives, though the historical nature is implied.
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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral details such as returning a pandas.DataFrame ordered from first to last page and that 'page' controls how many initial pages are fetched. It does not mention potential pitfalls like pagination limits or data freshness, but given the strong annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a docstring with a clear purpose line followed by parameter and return documentation. Every line adds value, such as the cross-reference to the total page function. It is not overly verbose, though the opening line is essentially the same as the annotation title, which is slightly redundant. Overall, it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description is sufficiently complete: it specifies the return type (pandas.DataFrame), the ordering of results, and links to a companion function for total pages. It lacks a breakdown of DataFrame columns, but there is no output schema to supplement this, and the nature of the data (administrative penalty details) is implied by the tool name and title. The read-only and idempotent annotations also cover operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all three parameters beyond the schema: 'page' indicates fetching the first N pages, 'begin' is the starting page, and 'item' lists explicit choices ('机关', '本级', '分局本级'). This is especially valuable because the schema has no per-parameter descriptions (coverage 0%). The only minor gap is the exact interaction between 'begin' and 'page' (e.g., does 'page' count from 'begin' or from page 1), which prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves data from a specific administrative penalty information disclosure table (行政处罚信息公开表) on the CBIRC branch page. The verb '获取' (get) plus the specific resource path ('首页-政务信息-行政处罚-银保监分局本级') makes the purpose unambiguous. It is easily distinguished from sibling tools, which cover unrelated domains like funds, futures, and macro 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching this table's data and provides useful context: use 'ak.bank_fjcf_total_page()' to obtain total pages for the 'page' parameter. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusion conditions, so it falls short of a 4. The guidance is embedded in parameter descriptions rather than a dedicated usage section.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds that it returns a pandas DataFrame of the composite index, but it does not disclose additional behavioral traits such as data coverage, update frequency, or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, URL, and param/return documentation. Although the parameter lists make it lengthy, each entry is necessary. It is front-loaded with the index name and source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 the return structure in more detail. It only says '新综合指数' (new composite index) and rtype pandas.DataFrame, leaving the DataFrame columns and their meaning vague. Parameter coverage is thorough, but the return value semantics are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two string parameters with defaults but no descriptions or enums. The description fully compensates by listing all valid choices for both indicator (17 options) and period (14 options), making it clear what values are accepted and what each represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the exact target as the ChinaBond Composite Index (中债-综合指数), including the source URL and hierarchy. This distinguishes it from sibling bond index tools like bond_index_general_cbond and bond_new_composite_index_cbond.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the ChinaBond Composite Index through its title and parameter documentation, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or context about preferability.
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?
Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds a valuable operational warning: heavy scraping may lead to IP bans, which is crucial for an agent deciding how often to call. It also mentions the return type, adding useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat disorganized, mixing a source URL, a caution, and docstring fragments in a single flow. Phrases like '实时行情数据' repeat, and the structure could be clearer (e.g., separating purpose, caveat, return type).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter spot data tool, it covers source, scope, return type, and a practical warning. However, it lacks details about the returned DataFrame's columns or data terms, which would help an agent interpret results. No output schema exists to fill this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description correctly indicates it returns all data for the current moment without requiring inputs. There is no need for parameter-level details, and the schema already fully covers the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches real-time market data for all Shanghai/Shenzhen convertible bonds from Sina Finance. The phrase '沪深可转债的实时行情数据' and '所有沪深可转债在当前时刻' precisely identifies the resource and scope, distinguishing it from sibling tools like daily or minute-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: this is for current-moment spot data, contrasting with historical daily/min tools. The warning '大量抓取容易封IP' provides a caution about frequency but does not explicitly compare with alternatives or state when to prefer this over siblings.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the return type (pandas.DataFrame) and the enumerated symbol choices, but does not disclose additional behavioral aspects such as data freshness, pagination, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, URL, parameter, and return sections. It is not overly verbose, but the inclusion of a URL is unnecessary for an agent and adds minor noise. The structure is clean and front-loaded with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 provides the essential information: it returns a pandas DataFrame with a fund list, and the parameter domain is fully enumerated. It lacks details on the DataFrame columns or any limitations, but for a basic list retrieval, the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'symbol' parameter (coverage 0%), so the description carries the full burden. It explicitly lists the allowed values ('封闭式基金', 'ETF基金', 'LOF基金') and the type (str), which adds meaningful semantics beyond the bare schema default. The parameter's optionality is not stated in the description but is present in the schema default, and the choices are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '新浪财经-基金列表' (Sina Finance Fund List) and specifies that it returns a fund list for the given symbol, with choices of closed-end, ETF, or LOF funds. This not only identifies the specific verb (list) and resource (fund categories from Sina) but also distinguishes it from the sibling tool fund_etf_category_ths by naming Sina as the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that it is used to retrieve fund lists by category but does not explicitly state when to prefer this over alternatives like fund_etf_spot_em or fund_etf_category_ths. There are no exclusions or alternative recommendations, leaving the agent to infer usage from the tool name and description.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds meaningful behavioral details: it specifies the exact return object (pandas.DataFrame) and defines all output columns with types (e.g., near_basis float, date string). It also discloses default behavior when parameters are omitted. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long due to the included URL and comprehensive return schema, but the information is well-organized: purpose, parameter docs, then return fields. Each line adds value, and the front-loaded purpose makes it easy to scan. The length is justified by the need to document both parameters and output columns in the absence of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no nested objects, the description is remarkably complete. It explains the purpose, parameter formats and defaults, and provides a full breakdown of all return columns with types and descriptions. This fully compensates for the missing output schema and gives the agent everything needed to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description fully documents both parameters: date accepts multiple formats (YYYY-MM-DD, YYYYMMDD, datetime.date) with a default, and vars_list is a list of contract varieties (e.g., RB, AL) with a default to all commodities. This adds substantial meaning beyond the bare schema and is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides spot prices and basis for commodities on a specified trading day. It is specific about the resource (commodity spot prices and basis) and distinguishes itself from sibling tools like futures_spot_price_previous in substance, though it does not explicitly name alternatives. A clear verb ('提供') and resource make the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameter defaults (empty date means today, empty vars_list means all commodities) but gives no guidance on when to choose this tool over closely related siblings such as futures_spot_price_previous or futures_spot_price_daily. There is no explicit mention of alternatives or exclusions, leaving the agent to infer usage context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the date lower bound (must be > 20100824), default behavior (current trading day), and return type (pandas.DataFrame), but does not disclose other behavioral aspects like error handling or rate limits. This is moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes essential elements: a title, source URL, parameter documentation, and return type. It is slightly redundant (the title is repeated in the return line) but overall well-structured and not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the necessary context: data source, parameter constraints, default behavior, and return type. It lacks details about the DataFrame columns or specific error behaviors, but these are not critical given the low complexity and the availability of a source URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter documentation. It provides detailed semantics for 'date': accepted formats (YYYY-MM-DD, YYYYMMDD, datetime.date), default value, and a minimum date constraint. This is highly informative, but the schema default '20050525' conflicts with the description's 'defaults to current trading day', which introduces confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (Zhengzhou Commodity Exchange) and the data type (daily volume and price data). The tool name 'get_czce_daily' adds the verb, and the description distinguishes it from sibling exchange-specific daily tools like get_dce_daily and get_shfe_daily.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the title and description: use this tool for CZCE daily volume/price data. However, there is no explicit guidance on when to choose this over other futures-related tools (e.g., get_dce_daily, futures_settle_czce), nor any mention of alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds useful behavioral context: accepted date formats, default to current trading day, returns a DataFrame with 11 listed columns, or None if no data for the given date. It does not disclose rate limits or source quirks, but the provided details go beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a title, source URL, parameter documentation, return description, and field list. Each section earns its place, and the column list is essential because there is no output schema. It is slightly verbose with repeated phrases but not excessive, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description fully covers invocation: parameter options and defaults, return type, column names, and the None edge case. The source URL adds transparency. The agent has all needed information to select and call the tool correctly, so completeness is excellent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows 'date' as a string with a placeholder default. The description greatly enriches this by explaining accepted formats (YYYY-MM-DD, YYYYMMDD, datetime.date), the actual default (current trading day), and accepted types. This compensates for the 0% schema description coverage. The slight mismatch between the schema default '20220415' and the described default 'current trading day' prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '上海期货交易所-日频率-量价数据', clearly indicating it retrieves Shanghai Futures Exchange daily volume-price data. The DataFrame column list further specifies the exact return data. It distinguishes from sibling exchange-specific getters by naming SHFE. However, it lacks an explicit verb like '获取/retrieves', relying on the tool name, so it is not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for SHFE daily data via the title and exchange name, but it does not explicitly state when to choose this tool over alternatives like get_futures_daily or other exchange-specific daily getters. It also does not mention any exclusions or preconditions. Guidance is only implicit, not explicit.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context by specifying the data range (19800201-present) and the return type (pandas.Series) with the current value in percent. This goes beyond the structured metadata without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is front-loaded with the essential purpose and data range. However, it includes two URLs and a docstring-style return annotation, which adds extra detail that may not be needed for tool selection. Overall, it is reasonably compact and well-structured, with a minor penalty for the cluttered inclusion of source links.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data retrieval tool, the description provides adequate contextual completeness: it states the data source, the covered period, and the return type (pandas.Series) with the unit (current value %). Combined with the strong annotations (read-only, idempotent, non-destructive), an agent has sufficient information to invoke the tool correctly without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the input schema is an empty object, so the baseline is 4 per the rubric. The description does not need to explain parameters; it correctly focuses on output semantics. No parameter-related gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the Australia Reserve Bank decision report ('澳洲联储决议报告') with a specific data range (19800201 to present). Although it lacks an explicit verb like 'get' or 'retrieve', the tool name and context make the purpose unambiguous. It distinguishes from sibling tools by naming Australia, though sibling differentiation is not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the name and the subject ('澳洲联储决议报告'), making it clear this is for Australian central bank rate data. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or references to sibling tools like other macro_bank_interest_rate options. The guidance is thus implicit rather than directive.
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?
注解已声明readOnlyHint=true、openWorldHint=true、idempotentHint=true和destructiveHint=false，覆盖了安全特征。描述额外提供了数据可用性限制（近一年）和返回类型（pandas.DataFrame），并包含了原始数据URL，增加了上下文价值。没有与注解冲突。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述较为简洁，包含了功能、参数、返回类型和数据源，长度适中。但docstring格式（如:param, :type, :return）对AI agent来说略显冗余，且标题信息在描述中重复出现，稍微影响了精炼度。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
作为只读数据获取工具，描述涵盖了核心信息：数据内容、来源、参数约束和返回类型（DataFrame）。由于没有输出schema，描述补充了返回值类型，足够引导agent使用。但缺少错误处理或超出日期范围时的行为信息，因此未达到满分。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
描述为start_date和end_date提供了中文含义和“不得超过一个月”的约束，这是有价值的补充。然而，schema覆盖率为0%，描述未能明确说明日期格式（如YYYYMMDD），虽然默认值暗示了该格式。参数语义基本清晰但仍有提升空间。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了工具提供FR007利率互换曲线历史数据，并附带了数据来源URL和近一年的数据限制。虽然没有显式的动作动词如“获取”，但结合工具名和返回类型，用途清晰。与同侪工具（如macro_china_lpr等）相比，FR007 swap rate 是独特的，因此具有区分度。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述明确指出了关键使用限制：只能获取近一年的数据，且开始和结束日期之间的跨度不得超过一个月。这些约束对正确调用至关重要。但描述未提及任何替代工具或何时应避免使用此工具，因此没有达到最高分。
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data source (East Money URL) and return type (pandas.DataFrame), which provides some extra context beyond annotations. However, it doesn't disclose data frequency, coverage limitations, or potential missing values, so transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the essential elements: the data source, URL, return value, and return type. Every line serves a purpose. It's slightly unstructured due to the raw docstring format, but it's appropriately sized for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides enough context: it states the data source, what is returned (unemployment rate), and the return type (DataFrame). It doesn't specify historical range or update frequency, but the low complexity and clear naming make the tool usable. Slight gaps exist, such as column details, but these aren't critical for the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% by default. The description doesn't need to explain parameter details. The baseline for 0 parameters is 4, and the description correctly omits any parameter information, as there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource: East Money economic data for Japan's unemployment rate (东方财富-经济数据-日本-失业率). It includes a source URL and return type, making it distinct from sibling tools for other countries' unemployment rates. The verb is implied (retrieve/get), but the intent 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when Japan's unemployment rate is needed, and the name distinguishes it from other country-specific tools. However, it provides no explicit guidance on when to choose this tool over alternatives, and doesn't mention any exclusions or prerequisites. Usage is inferred rather than stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the data source (East Money, with URL) and the return type (pandas.DataFrame), which is useful beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, but it contains some redundancy by repeating the title in the first line and then again in the return annotation. The URL is useful context but not strictly necessary. Overall, it is concise and structured with clear return information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, no-parameter tool with no output schema. The description tells the agent exactly what data it returns (GDP quarterly rate preliminary value), in what format (pandas.DataFrame), and from where (East Money URL). This is fully sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description provides no parameter-level details because none exist, which is appropriate and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing UK GDP quarterly rate preliminary value from East Money, and the name distinguishes it from yearly GDP tools. However, it lacks an explicit verb like 'retrieve' or 'get', relying on the noun phrase and tool name to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the data type and source but gives no explicit guidance on when to use this tool versus alternatives such as macro_uk_gdp_yearly. Usage is implied by the 'quarterly' qualifier and the tool name, but no direct comparison or exclusion is provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety traits. The description adds useful context beyond annotations, such as the data source URL and the specific return type (pandas.DataFrame) containing call/put real-time quotes. No contradiction; it is a read-only data fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a clean docstring structure with title, source URL, :param, :type, :return, and :rtype sections. Every line adds value, there is no redundancy, and the purpose is front-loaded. It is extremely compact yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey return structure. It states the return is a pandas.DataFrame of call/put real-time quotes, but it does not list expected columns or clarify the default symbol behavior. For a simple real-time quote tool with a cross-reference for symbol discovery, this is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero description coverage for the 'symbol' parameter, so the description must compensate. It does define symbol as '合约代码' (contract code) and points to option_cffex_hs300_list_sina for finding valid values, which adds meaning. However, it does not explain the symbol format or provide examples beyond the default, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides real-time quotes ('实时行情') for specified contracts of CFFEX HS300 index options, and the return type mentions call/put quotes. It distinguishes itself from sibling tools like option_cffex_hs300_list_sina and option_cffex_hs300_daily_sina by emphasizing '指定合约' and '实时行情'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use the tool (for real-time quotes of a specific contract) and explicitly directs users to option_cffex_hs300_list_sina to obtain valid symbol values. However, it does not explicitly discuss alternatives (e.g., daily data) or when not to use this tool, so usage guidance is mostly implied.
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?
The description adds a behavioral detail—the first returned contract is the main contract—beyond the readOnlyHint and idempotentHint annotations. It does not disclose potential quirks like pagination or data format nuances, but for a simple read-only list tool, the annotation coverage plus this detail 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it repeats the resource phrase twice (once in the main sentence and again in the :return: line). The added note about available indices is useful context but could be trimmed. Overall, it is concise and structured with a clear return type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), and the description explains what is returned (all contracts, first contract is main) and the return type (dict). It does not detail the dict structure, but for a list-style endpoint, this is acceptable given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers all parameters (100%). Per the baseline for 0-param tools, no further parameter explanation is needed, and the description appropriately focuses on output semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (CFFEX CSI 1000 index options from Sina Finance) and the action (returns all contracts), and notes the first contract is the main contract. This distinguishes it from sibling tools like option_cffex_hs300_list_sina by explicitly naming the index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage context by stating that only CSI 300 and CSI 1000 index futures/options are currently available on Sina Finance, which hints at when this tool is relevant versus the CSI 300 sibling. However, it does not explicitly name alternatives or state when not to use this 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context: it specifies the return type (pandas.DataFrame) and the required symbol format (e.g., '原油期权'). It does not mention potential errors, data scope (e.g., per-contract vs. per-variety margin), or data source, leaving some behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a compact docstring: it front-loads the purpose in the first line, then clearly documents the parameter and return value. Every sentence adds value—no redundancy or filler—and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only tool with a single optional parameter, the description covers purpose, parameter semantics, and return type. It also directs users to a sibling tool for the symbol list. It could be more complete by detailing the output DataFrame columns or clarifying what 'margin' includes (initial, maintenance, etc.), but it is largely sufficient given the tool's simplicity and strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the parameter name and type without any description. The description fully compensates by explaining that 'symbol' is a commodity option variety name, giving an example ('原油期权'), and referencing the helper function ak.option_margin_symbol() to obtain all valid codes and names. This is thorough and exceeds schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with '获取商品期权保证金' (Get commodity option margin), which is a clear verb+resource statement. It identifies the tool's purpose and distinguishes it from sibling tools like option_margin_symbol (which retrieves symbols) by focusing on margin data. However, it doesn't explicitly differentiate from other option data tools such as option_premium_analysis_em, so it falls short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need commodity option margin) and provides a helpful pointer to ak.option_margin_symbol() for obtaining valid symbol names. It does not, however, state when not to use this tool or explicitly name alternative tools, so usage guidance remains largely implicit.
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?
Annotations already declare readOnly=true, idempotent=true, destructive=false. The description adds context about token storage ('记录自己的token凭证') and temporary token handling, which goes beyond the annotation defaults. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the purpose ('初始化 pro API') and efficiently covers both token-setting mechanisms. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple initialization tool with one parameter, the description covers the main usage modes but doesn't explain the return value, whether the tool must be called before all others, or how it relates to sibling tools set_token and get_token. The overlap with siblings creates an ambiguity gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It clarifies that the token parameter is for a temporary token, adding meaning beyond the bare schema. However, it lacks details about format, requiredness, or behavior when combined with set_token.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool initializes the pro API, which is a specific verb+resource. It distinguishes itself from siblings like set_token and get_token by focusing on initialization context, though it doesn't explicitly name the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: either persist a token via ak.set_token or pass a temporary token in the parameter. It implies the initialization context but doesn't explicitly state when not to use it or compare with alternatives like set_token.
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?
Annotations already establish this as a read-only, idempotent, non-destructive operation. The description adds the behavioral constraint that the date range must be within one month, which is not captured by annotations or schema, and discloses the return type (pandas.DataFrame). This adds value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured docstring with clear tagged sections for parameters and return. Every line serves a purpose: title, source URL, param semantics, and return type. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description covers the core aspects: purpose, source, parameter constraints, and return type. It does not describe the DataFrame columns or behavior when the date range exceeds one month, but these are secondary for a low-complexity historical data fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description's param docs are essential. They explain that start_date and end_date are start/end times and that they must be within one month. However, the expected date format (e.g., YYYYMMDD) is not explicitly stated, only implied by the defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing historical repo fixing rate data from the China Foreign Exchange Trade System, with the return line confirming it returns historical data. However, it lacks an explicit action verb and does not explicitly differentiate from the sibling tool repo_rate_query, though the '历史数据' phrasing implies historical vs current.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides parameter-level guidance, especially the critical constraint that start and end dates must be within one month, but offers no explicit guidance on when to choose this tool over alternatives such as repo_rate_query. No exclusions or alternative tool references are given.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the return type (pandas.DataFrame) and the data source URL, which is useful. However, it does not disclose behavior beyond that, such as potential network dependency, data availability for specific periods, or error cases. The return type and source add some value, but no deeper behavioral traits are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a clear title, followed by a URL and parameter documentation. It avoids unnecessary fluff. The URL might be redundant but does not detract from clarity. The docstring structure is efficient, though it lacks a prose explanation that could further aid understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should list or hint at the returned columns, but it only states '资产负债表-按报告期' and the return type. For a simple tool with one parameter, the purpose and parameter are well covered, but the absence of any field names or example data leaves the agent uncertain about the exact structure of the returned DataFrame. Sibling tools likely have similar output, but the description does not reference them for guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies a string parameter with a default. The description compensates by explaining that the symbol is a delisted stock code with a market identifier (带市场标识), and the default 'SZ000013' illustrates the expected format. This provides complete semantic meaning for the only parameter, fully closing the 0% schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing balance sheet data for delisted stocks by reporting period, sourced from East Money. The hierarchical label (东方财富-股票-财务分析-资产负债表-已退市股票-按报告期) specifies both the domain and the exact filter (delisted stocks, by report), effectively distinguishing it from sibling tools like stock_balance_sheet_by_report_em (for listed stocks) and stock_balance_sheet_by_yearly_em (yearly reports). The verb is implicit but the resource and scope are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning '已退市股票' (delisted stocks), so an agent can infer this tool is for retrieving balance sheets of delisted companies by reporting period. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no mention of prerequisites such as how to identify delisted stock codes or that other tools should be used for active companies.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source URL and return type (pandas.DataFrame) but does not disclose other behavioral traits such as rate limits, date format constraints, or empty-result behavior. Since annotations cover the main safety aspects, this is acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear title line, a source URL, and parameter documentation. Every line carries meaningful information with no redundancy or filler. 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters and no output schema, so the description should cover return semantics and usage context. It states the return is '历史行情' as a DataFrame, which is sufficient for basic use, but it lacks details about the columns, the list of valid sector symbols, and how it compares to the many sibling board-related tools. This leaves some ambiguity for an agent deciding among similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden of explaining parameters. It provides Sphinx-style docs for all five parameters, including explicit choices for period ('日k', '周k', '月k') and adjust ('', 'qfq', 'hfq'). However, it does not specify the date format for start_date/end_date beyond the defaults, and symbol values are described only as '板块名称'. This is helpful but has minor gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '东方财富网-沪深板块-行业板块-历史行情', clearly stating it provides historical quotes for Shanghai/Shenzhen industry sectors from Eastmoney. This specific verb+resource combination distinguishes it from sibling tools like stock_board_industry_spot_em (spot) and stock_board_industry_cons_em (constituents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the word '历史行情' (historical quotes) and the source URL, but it provides no explicit guidance on when to use this tool versus alternatives such as stock_board_industry_spot_em or stock_board_industry_hist_min_em. There are no exclusion criteria or prerequisites mentioned, so it only partially addresses usage context.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that this returns a pandas DataFrame from a specific Futu page, but does not disclose any additional behavioral traits such as data freshness, pagination, or rate limits. It is consistent with annotations and adds minor value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured as a docstring with sections for symbol, type, return, and a source URL. Every line adds value: the title, the URL, the parameter explanation, and the return type. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description provides sufficient context: the data source (Futu sparks-us page), the valid parameter values, and the return type (DataFrame). It could potentially mention the market (US) but the URL and concept names imply it, so it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines symbol as a string with a default and no description or enum values (schema coverage 0%). The description fully compensates by listing the exact allowed choices (巴菲特持仓, 佩洛西持仓, 特朗普概念股) and explaining that symbol is the sector name, giving the agent complete information to select a valid value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning constituent stocks of Futu's concept sectors (富途牛牛-主题投资-概念板块-成分股), with a specific source URL. It distinguishes itself from other concept tools by naming the Futu source and listing the exact selectable concept names, making the tool's scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the limited symbol choices (e.g., 巴菲特持仓, 佩洛西持仓, 特朗普概念股) and the Futu-specific focus, but it does not explicitly state when to use this tool over alternatives like stock_concept_cons_em or provide exclusion criteria. No alternatives are mentioned, so usage 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds that it fetches data for a specified market and time period, but does not provide additional behavioral details such as rate limits, pagination, or data freshness. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a docstring with a title, URL, parameter descriptions, and return type. Every sentence adds value, and it is appropriately sized without unnecessary fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: source, parameters, return type, and scope. Given the simple nature of the tool and the presence of thorough annotation hints, it is reasonably complete. It does not detail the exact columns of the returned DataFrame or clarify the concept of 'institution statistics,' but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter: market with an explicit enumeration of allowed values, and start_date/end_date with format examples (YYYYMMDD). This adds significant meaning beyond the raw schema, making it clear how to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves daily individual stock institutional statistics from Eastmoney's Stock Connect holdings data center, with a specific URL and parameters. The title and description together specify the exact resource and scope (market and date range), distinguishing it from sibling tools like stock_hsgt_stock_statistics_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. It describes the parameters and return type but does not mention any exclusions, prerequisites, or situations where other tools would be more appropriate. Usage is only implied by the function 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the source URL and the list of valid symbols, but does not disclose behavioral traits such as whether data is historical or current, data granularity, or any rate limits or authentication requirements. It goes barely beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter specification, and return type. It is front-loaded with the title, and every line is informative without unnecessary verbosity. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no output schema, the description adequately covers purpose, input choices, and return type. It lacks details about the exact contents of the returned DataFrame (e.g., columns, time range), but given the tool's simplicity and the provided annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'symbol' with no description and no enum, but the description provides a complete enumeration of accepted values: 上证50, 沪深300, 上证380, etc. This is critical for correct usage and fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves index PE ratio data from Legulegu ('乐咕乐股-指数市盈率') and documents the return as '指定指数的市盈率数据' (PE data for the specified index). This distinguishes it from sibling tools like stock_index_pb_lg (PB ratio) and stock_market_pe_lg, as it focuses specifically on index PE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching PE data for one of the listed Chinese indices, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools. The usage context is clear from the title and return description, but not explicitly articulated.
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 already declare the tool as read-only, idempotent, and non-destructive. The description adds the data source (Eastmoney), the URL, and that it returns a pandas DataFrame of recent data, but does not disclose any additional behavioral nuances such as data update frequency or row count. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a source title, URL, and return type. It is front-loaded with the resource name and avoids unnecessary prose, though the URL is somewhat redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, the description provides enough context: it identifies the data source, the specific dataset (market-wide fund flow), and the return type. An output schema is absent, but the return type is mentioned, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully descriptive. The description adds no parameter information, but none is needed. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent market-wide fund flow data (大盘资金流) from Eastmoney, with a specific URL as evidence. This distinguishes it from sibling tools that focus on sector or individual fund flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent market-wide fund flow data, but provides no explicit guidance on when to choose this tool over alternatives like stock_sector_fund_flow_rank or stock_individual_fund_flow. No exclusions or conditions 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the return is a pandas.DataFrame and identifies the data source (东方财富), but it does not disclose any additional behavioral traits such as how missing symbols are handled or data update frequency. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with title, URL, parameter, type, return, and return type, making it scannable and appropriately sized. The URL adds reference value without excessive verbosity, and every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional parameter and no output schema, the description explains the main input and states that the return is a pandas.DataFrame containing the quarterly income statement. It does not enumerate columns or edge-case behaviors, but given the tool's simplicity and the provided source link, it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully defines the 'symbol' parameter as the stock code with market identifier (股票代码; 带市场标识) and provides an example URL containing 'sh600519', clarifying the expected format. This compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the income statement (利润表) by single quarter (按单季度) from Eastmoney's financial analysis section. It explicitly includes a URL and specifies the return type, effectively distinguishing it from sibling tools like stock_profit_sheet_by_yearly_em or stock_profit_sheet_by_report_em via the '按单季度' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a parameter specification and notes that the symbol must include the market identifier (带市场标识), which is helpful. However, it does not explicitly state when to use this tool over alternatives (e.g., yearly or report-based versions). The usage context is implied by the tool name and quarterly qualifier, but no direct when-to-use guidance is given.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a reference URL, parameter format, and return type (pandas.DataFrame), but does not disclose potential caveats like data source latency, authentication needs, or the specific columns returned. It provides some value beyond annotations but lacks rich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a descriptive title, a helpful reference URL, and standard param/return docstring lines. Every part contributes value without unnecessary verbosity, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, the description adequately states the return type (pandas.DataFrame) and scope (delisted stocks by reporting period). However, it does not describe the DataFrame's columns or data granularity, which an agent would need to interpret results. Given the large family of similar tools, a brief note on the data content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines symbol as a string with a default, but the description explains that symbol must be a delisted stock code with a market identifier (带市场标识), adding meaningful semantics beyond the schema. It also gives a concrete example (SZ000013), though it could list valid market prefixes explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's title clearly states the tool's function: Eastmoney stock financial analysis income statement for delisted stocks by reporting period. It specifies the resource (income statement), scope (delisted stocks), and period type (by report period), distinguishing it from siblings like stock_profit_sheet_by_report_em (for active stocks) and stock_profit_sheet_by_yearly_em.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for delisted stocks' income statements by report period through its title, but provides no explicit guidance on when to use this tool versus alternatives. It does not name alternative tools for non-delisted stocks or different period granularities, nor does it mention any exclusions or prerequisites.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type but does not disclose additional behavioral traits such as data volume, columns, or potential delays. With annotations present, the description adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, comprising a clear title line, a helpful source URL, and return type information. It is front-loaded with the key purpose and contains no unnecessary filler, though it could have omitted the URL without losing core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description provides adequate context: data source, market, data type, and return format. It does not describe the DataFrame columns, but given no output schema and the simplicity of a spot quote tool, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description correctly notes the return type (pandas.DataFrame) but adds no parameter-specific details since there are none. Baseline 4 applies for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides real-time quotes ('实时行情') for Shenzhen A-shares ('深 A 股'), specifying the exact market and data type. This distinguishes it from sibling tools like stock_sh_a_spot_em (Shanghai A-shares) and stock_bj_a_spot_em (Beijing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for Shenzhen A-share quotes but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or name sibling tools, so the usage context is only implicit.
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 already indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds the data source (Tencent Finance) and return type (pandas.DataFrame), which is useful but does not disclose any behavioral quirks like date range inclusivity, symbol format requirements, or handling of missing data. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a structured docstring format with a clear title, a source URL, and parameter descriptions. It is concise, with no redundant phrases, and each line adds meaning. The URL is arguably extra but serves as a reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying the DataFrame return type and the data source. However, it leaves gaps: the symbol format is ambiguous (the URL shows 'hk01033' but the default symbol is '02318'), and the adjust parameter's empty default is not explained. The description is adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides explicit ':param' entries for all four parameters: symbol, start_year, end_year, and adjust, including type hints and examples. The adjust parameter maps 'qfq' to forward adjustment and 'hfq' to backward adjustment, which adds meaning beyond the bare string schema. However, it does not clarify the expected format of symbol (e.g., with or without 'hk' prefix) nor the behavior when adjust is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '腾讯财经-港股-AH-股票历史行情' (Tencent Finance HK AH stock historical quotes) and the return line specifies '指定股票在指定年份的日频率历史行情数据' (daily frequency historical market data for a given stock in a given year). This is a specific verb+resource combination that distinguishes it from sibling tools like stock_zh_ah_spot, which provides real-time spot data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving daily historical data for AH stocks via the return line, but it does not explicitly state when to use this tool over alternatives such as stock_zh_ah_spot or stock_zh_ah_name, nor does it mention exclusions or prerequisites. The absence of cross-references to siblings leaves the selection criteria implicit.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the source URL and confirms the return type as pandas.DataFrame, but does not disclose potential rate limits or data freshness, which is acceptable for a read-only spot quote 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a title, source URL, and return type in three short lines. Every element adds information; the URL is useful for source verification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with strong annotations, the description provides the essential behavior: returns real-time quotes for all A-shares from Eastmoney as a DataFrame. No output schema exists, but the tool's simplicity and the description's clarity keep it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is trivially 100%. The description correctly adds no parameter information, and the baseline for zero-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns real-time A-share quotes from Eastmoney, covering Shanghai, Shenzhen, and Beijing. The name 'stock_zh_a_spot_em' and the title '东方财富网-沪深京 A 股-实时行情' explicitly distinguish it from exchange-specific or alternate-source sibling 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/5Does 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 stock_sh_a_spot_em or stock_zh_a_spot. The description only states what the tool does, without describing 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context by specifying the return type (pandas.DataFrame) and the meaning of the output (profit probability Y%), which goes beyond the annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat scattered, mixing a Chinese summary, an example API URL, and parameter documentation. It is concise in length but lacks a clear, structured layout. Each part contributes some value, but the organization could be improved for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the key aspects: purpose, parameters, return type, and source. It does not detail the exact format of the returned DataFrame, but given the tool's simplicity and the presence of annotations, the information is largely sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description documents both parameters: symbol is 基金代码 (fund code) and timeout is 'choice of None or a positive float number'. This provides meaningful semantics beyond the schema's type/default definitions. However, it does not elaborate on the DataFrame structure or further constraints on timeout.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it computes the profit probability of a fund when bought at any historical point and held for X years. The specific metric (盈利概率), source (雪球基金), and scenario (历史任意时点买入，持有满 X 年) are explicit, distinguishing it from sibling fund tools like basic info or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (querying fund profit probability) but does not explicitly mention when to use this tool over alternatives or provide exclusions. Sibling tools exist (e.g., fund_individual_basic_info_xq), but no comparison is given. Usage context is present but not fully articulated.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the source URL and return type but no additional behavioral context such as data availability or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with the core purpose front-loaded. The URL and docstring-like elements add a bit of clutter but still keep it compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with rich annotations, the description adequately covers purpose, parameter format, and return type. It does not describe output fields, but no output schema exists and the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting the date parameter with meaning ('交易日'), format, and an explicit example ('20240122'). This is exactly what an agent needs to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Guangzhou Futures Exchange (GFEX) warehouse receipt daily data, with a specific resource and exchange. It distinguishes itself from sibling tools like futures_shfe_warehouse_receipt or futures_warehouse_receipt_czce by naming GFEX explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 GFEX identifier gives implicit usage context, but there is no mention of exclusions or when to prefer this over sibling tools for other exchanges.
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 already indicate read-only, non-destructive, idempotent behavior. The description adds context about the default date (current trading day), accepted date formats, and the return type (pandas DataFrame), which are useful. It does not mention edge cases like non-trading-day inputs or data availability limitations, but overall it supplements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-organized docstring with summary, product info, source URL, and parameter/return documentation. Each line provides distinct value, though the return and rtype lines somewhat repeat the opening summary. It is concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool without an output schema, the description covers the essential context: source URL, product, date semantics, and return type. It could be improved by listing DataFrame columns or explicitly stating the scope is limited to the industrial silicon contract, but given the simplicity and annotations, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with no description coverage. The description thoroughly documents the 'date' parameter, specifying supported formats (YYYY-MM-DD, YYYYMMDD, datetime.date), the default behavior, and its type. This fully compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Guangzhou Futures Exchange daily volume-price data (广州期货交易所-日频率-量价数据) and specifies the product (industrial silicon, listing date 20221222). This identifies the exact resource and differentiates it from sibling exchange-specific tools like get_cffex_daily or get_dce_daily.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when GFEX daily data is needed, and the name and product detail make the exchange clear. However, it does not explicitly name alternative tools for other exchanges nor state when not to use this tool, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds valuable context about the df parameter: it fetches data from dailyBar internally if df is None, and passing df speeds up computation. This discloses internal data fetching and performance implications, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a short purpose statement followed by a clean parameter list. Each line is necessary and front-loaded with the core functionality. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description explains inputs and purpose well, it does not mention what the function returns (e.g., a scalar, tuple, or DataFrame). With no output schema, this is a notable gap. However, given the tool's relative simplicity and strong annotations, it remains adequately complete for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining every parameter: date format (YYYYMMDD), var examples (RB, AL), symbol examples (rb1810, rb1812), and df's role and optionality. This is detailed and actionable, far exceeding baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes roll yield for a specified trading day, either for a specified variety using main/second main contracts or for any two given contracts. This is specific and distinguishes it from siblings like get_roll_yield_bar which likely returns a time series. 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/5Does 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, prerequisites, or use cases. The only contextual hint is the performance note about passing df, which does not address tool selection.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by specifying the return type (pandas.DataFrame) and providing per-indicator year availability, which helps the agent understand data constraints beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a title, source URL, parameter documentation, and return type. It is somewhat lengthy due to the year mapping, but every section contributes useful information, and the front-loaded title and URL provide clear context without excessive fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, no output schema, and read-only annotations, the description covers the essential aspects: what the tool does, what parameters are valid, and the return type. It lacks examples or error-handling notes, but for a simple data retrieval tool, the provided details are largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility. It thoroughly documents the 'indicator' parameter with an explicit choice list and the 'year' parameter with per-indicator valid ranges, adding substantial meaning beyond the plain string schema. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Hurun ranking data for a specified indicator and year, with a list of available indicators. It is specific about the resource (Hurun rankings) and the action (retrieve data), though it does not explicitly contrast with sibling ranking tools like forbes_rank or xincaifu_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by enumerating valid indicators and year ranges, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The parameter documentation gives practical constraints, but there is no direct guidance on selection among the many ranking tools in the sibling list.
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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the source URL and return type (pandas.DataFrame), which is slight additional context, but no behavioral details such as data range, update frequency, or rate limits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line identifying the indicator and source, a URL, and a return type annotation. No redundant information; every element contributes useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and is a simple read-only data retrieval operation, the description sufficiently covers the source, return type, and purpose. It does not detail DataFrame columns or update schedule, but the low complexity and rich annotations make this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and schema coverage is effectively 100% (no properties). The description mention of the return type provides some semantic value, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the resource (Consumer Confidence Index from Eastmoney) and provides the source URL. It clearly distinguishes this tool from other macro_china_* siblings by the specific indicator name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement about when to use this tool versus alternatives, but the indicator name and source URL make the use case implied. No exclusions or alternative 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which cover safety expectations. The description adds the source URL and return type (pandas.DataFrame), providing some context about return format, but does not disclose further behavioral details like data granularity or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a title line, a source URL, a return value line, and a return type line. Every line earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description includes the source, the exact indicator, the frequency, and the return type. It could be more explicit that it returns a time series of historical monthly values, but it is largely complete for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline score of 4 applies. The description adds no parameter-specific meaning, but none is needed. It does document the return value and type, which is useful context for the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '东方财富-经济数据-英国-零售销售月率' (Eastmoney - Economic Data - UK - Retail Sales Monthly Rate) and specifies the return value as '零售销售月率' (retail sales monthly rate). This distinguishes it from sibling macro_uk_retail_yearly by frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about the data returned but gives no explicit guidance on when to use this tool versus alternatives. Sibling tools like macro_uk_retail_yearly exist, but no exclusions or alternatives are mentioned. Usage is implied by the name and description.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context beyond these annotations: the specific data range (19970801-至今), a source URL, and the return type (pandas.DataFrame). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first line states the report type and data range, followed by a source URL and return type. Every line earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only data retrieval tool, the description covers the essential details: what data, the time range, the source, and the return type. It omits column-level documentation or refresh frequency, but these are not critical for selecting and invoking this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers parameter semantics. The description adds no parameter-specific details, but none are needed. Baseline for 0 params is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '美国ISM非制造业PMI报告' (US ISM Non-Manufacturing PMI Report) with a data range (19970801-至今), clearly identifying the tool's resource and scope. It distinguishes from sibling tools like macro_usa_ism_pmi by specifying '非制造业' (non-manufacturing). The source URL and return type further reinforce the 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/5Does 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 related tools such as macro_usa_ism_pmi or macro_usa_services_pmi, nor any exclusions or prerequisites. The usage context is only implied by the tool name.
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 already declare readOnlyHint, idempotentHint, and destructiveHint as safe, so the description only needs to add extra context. It adds that the tool returns a pandas DataFrame and that symbols include call/put identifiers, but it does not disclose potential rate limits, network dependence, or field contents. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a standard docstring format with param, type, return, and rtype sections. Every line adds value, with no redundant fluff. The title is informative and the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with rich annotations and no output schema, the description provides enough context: what data it returns, how to get a valid symbol, and the data source. It could provide example symbols or list expected columns, but such detail is not strictly necessary given the tool's simplicity and the cross-reference for symbol discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It does so effectively: symbol is described as the specific contract code including call/put indicators, and a method to discover valid values is provided via a cross-reference to another function. The type in the schema is string, and the description adds semantic meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: retrieving daily-frequency market data for a specified SSE 50 index option contract from CFFEX via Sina Finance. The noun phrase '日频行情' and the resource specificity distinguish it from sibling tools like option_cffex_hs300_daily_sina and option_cffex_sz50_spot_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the '日频' (daily frequency) return type and the title, indicating it is for historical daily data. However, it does not explicitly contrast with spot/list tools or state when not to use this tool. It does provide a helpful pointer for obtaining valid symbol values from option_cffex_sz50_spot_sina.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing the core safety profile. The description adds the source URL and allowed symbol values, but does not disclose additional behavioral traits such as pagination, rate limits, or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter documentation, and return type. Each line serves a purpose with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters, the description provides enough to invoke it: data source, parameter semantics, and return type (pandas DataFrame). It does not enumerate output columns, but the implied-volatility context and return type suffice given the simplicity and annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description carries the burden. It adds meaning for both parameters: symbol is limited to {'工业硅', '碳酸锂'} and trade_date is a trading day. However, the exact date format is not explicitly stated, relying on the default value '20230724' to imply YYYYMMDD.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing daily-frequency contract implied volatility data from the Guangzhou Futures Exchange (广州期货交易所). It specifies the resource (GFEX implied volatility), scope (daily frequency, contracts), and includes a source URL, distinguishing it from sibling tools like option_vol_shfe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied by the title and name (GFEX implied volatility), but no alternative tools are mentioned and no conditional guidance is given.
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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, providing a clear safety profile. The description adds context about data source (Eastmoney), cleaning/formatting, and return columns, but does not disclose limitations, rate limits, or error behavior beyond that. It adds some value but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and front-loaded with the main purpose, followed by a URL and a detailed parameter list. The URL is somewhat unnecessary noise, but the rest is informative and well-organized. It is appropriately sized for the complexity of the tool, though slightly verbose due to the docstring-style parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema), the description covers the return type and columns, parameter semantics, data source, and purpose. It lacks usage guidance and potential pitfalls, but overall it provides sufficient context for an agent to invoke the tool correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes a full docstring explaining each parameter's meaning, type, format, and allowed values. For example, period lists {'1','5','15','30','60'} and adjust explains options like qfq and hfq. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches stock minute-level data from Eastmoney, cleans it, and formats it for yz realized volatility calculations. This specific verb+resource+purpose distinguishes it from sibling tools like stock_zh_a_hist_min_em which likely returns raw minute data without the yz-specific formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining minute data in the yz realized volatility format but does not explicitly state when to use this tool over alternatives. There are no exclusionary conditions or mentions of alternative tools (e.g., raw minute data via stock_zh_a_hist_min_em), so guidance is only implied via the purpose.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return type and source URL but provides no additional behavioral context such as data update frequency or potential delays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three lines covering source, URL, and return type. Every element is useful, with the key information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description provides sufficient context: source, resource, and return type. It could specify the exact DataFrame structure, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already fully covers the input space. Per rubric, a zero-parameter tool receives a baseline of 4; the description adds nothing about parameters but also needs no additional clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns industry board names from Eastmoney (东方财富网) as a pandas DataFrame. It clearly specifies the resource (industry boards) and differentiates from sibling tools like stock_board_industry_name_ths by naming the data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool vs. alternatives. Usage is implied only by the name and return type; no alternatives or exclusions 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source URL and return type, but no further behavioral details like pagination or column specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with title, URL, parameter documentation, and return type. Each line serves a purpose, and 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema, the description covers the data source, parameter choices, and return type. However, it does not detail the DataFrame's columns or content, which would be helpful since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with only a default value; the description compensates by listing the four valid choices for symbol (创月新高, 半年新高, 一年新高, 历史新高). This adds meaningful guidance beyond the schema's type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves stock screening data for '创新高' (new highs) from 同花顺 (THS) data center, with a provided URL. It distinguishes itself from sibling rank tools by specifying this specific category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for screening stocks hitting new highs, and the parameter choices define time periods, but it does not explicitly state when to use this versus alternative ranking tools or 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns a pandas DataFrame with the review results and includes the source URL, but it does not disclose other behavioral traits like pagination, data freshness, or rate limits. It adds some value but is not especially rich in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact string that front-loads the data source, includes the direct URL, and specifies both the return value and type (:return: and :rtype:). Every element earns its place, with no redundant or filler text. It is as concise as possible while conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete: it names the source, gives the URL, and states the return type and content. It does not list DataFrame columns or mention potential caveats like data delay, but these are not critical for a basic read-only retrieval tool. The provided information is sufficient for an agent to invoke and understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is trivially complete. The description provides no parameter details because none are needed. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description does not need to compensate for any missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing IPO review information for the ChiNext (创业板) registration system from Eastmoney's data center, with a specific source URL and return type. It distinguishes itself from sibling register tools like stock_register_kcb or stock_register_sz by specifying 创业板 (ChiNext) and 注册制审核结果 (registration review results). The verb is implicit but the function name 'stock_register_cyb' reinforces retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the data source and what it returns, but it does not explicitly mention when to use this tool over alternatives or provide exclusion criteria. The URL suggests a direct data retrieval use case, but there is no comparative guidance against sibling tools like stock_register_all_em or stock_register_kcb. It provides clear context but lacks explicit when-not or alternative suggestions.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the source URL and return type (pandas.DataFrame) but does not disclose additional behavioral traits such as data freshness, pagination, or network requirements beyond what openWorldHint implies. This adds some context but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes the essential information: source, category, board, URL, and return type. It is structured with line breaks. However, it repeats '深圳主板' twice (in the title and the return line), which is slightly redundant, but overall it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with rich annotations, the description provides core information about the data source and return type. However, since there is no output schema, it would be helpful to describe the DataFrame's columns or structure, which is absent. 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is no parameter ambiguity. The description does not need to explain parameter meanings; the baseline score of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the data source (East Money Data Center), the category (New Stock Data - IPO Review Information), and the specific market segment (Shenzhen Main Board). The ':return:' line confirms the tool returns data, and the URL provides the exact source. This differentiates it from sibling tools like stock_register_sh or stock_register_kcb, which target different boards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool retrieves IPO review information for the Shenzhen Main Board, which is sufficient to guide an agent when to use it (when such data is needed). However, it does not explicitly mention alternatives or state when not to use it, so it falls short of full guidance but is still clear.
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?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by disclosing the 15-minute delay, which is critical for data freshness. It also specifies the return type as pandas.DataFrame, though this is partly structural.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only the source name, URL, return value, delay, and return type. Every line adds value, and there is no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description covers the essential aspects: source, data content, delay, and return type. However, it does not list columns or explain the structure of the DataFrame, which could be useful given the absence of an output schema. Still, the tool's simplicity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is nothing to explain. Per the rubric, a no-parameter tool receives a baseline of 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns '美股-实时行情' (US stock real-time quotes) from Eastmoney, with a source URL. It identifies the specific resource and differentiates from historical or daily tools by emphasizing '实时' (real-time) and the 15-minute delay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools like stock_us_spot, stock_us_famous_spot_em, and stock_us_pink_spot_em exist, but no distinguishing conditions or exclusions are mentioned.
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?
The description discloses a key behavioral trait beyond annotations: it only provides closing prices ('只有收盘价') and returns a DataFrame with date and close price. This adds context about data limitations. Annotations already declare read-only and idempotent hints, so the description complements rather than repeats them. No hidden side effects or rate limits are mentioned, but the safety profile is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a title, a crucial P.S. note, a reference URL, and docstring-style parameter explanations. It is not overly long and each part adds value: the P.S. carries the most important usage caveat, the URL provides a source reference, and docstrings define parameters. The content is front-loaded with the caveat right after the title, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple read-only tool with three parameters, the description covers the essential context: what data is returned (dates and closing prices), when to use it (only for indices exclusive to CSIndex), and parameter meanings. It lacks a few details like date format, but defaults and examples fill that gap. No output schema exists, so the return description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the three parameters (coverage 0%), but the description includes docstrings explaining each: symbol is the index code with an example, start_date and end_date are start/end dates (format implied by defaults). This effectively compensates for the schema gap. It does not specify date format explicitly, but the defaults in the schema (e.g., 20240604) make it clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving historical market data for a specific CSI index ('中证指数-具体指数-历史行情数据'). The P.S. adds that it only returns closing prices and normally shouldn't be used unless the index is exclusive to the CSIndex website, which distinguishes it from other index data tools. However, it lacks an explicit action verb like 'fetch' or 'get', relying on the noun phrase to imply the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The P.S. provides explicit guidance on when to use this tool: '正常情况下不应使用该接口，除非指数只有中证网站有' (normally should not use this interface unless the index is only available on the CSIndex website). This clearly states a when-not condition and implies alternatives, but it does not name specific alternative tools, stopping short of a 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a pandas DataFrame and provides the source URL, but does not disclose data volume, columns, time range, or other behavioral aspects. Minimal added context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines containing the Chinese name, a URL, and return type information. Every sentence carries essential information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter, read-only tool with strong annotations, the description is complete. It states the data source, return type, and what the data represents. The lack of an output schema is mitigated by the clear return type declaration (pandas DataFrame).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object, so there is nothing to explain. The baseline for 0 params is 4, and the description does not need to compensate for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns '平衡混合型基金仓位' (balanced hybrid fund position) as a pandas DataFrame, which is a specific verb+resource+scope. This distinguishes it from sibling tools like fund_stock_position_lg and fund_linghuo_position_lg which target different fund categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the exact fund category (balanced hybrid), but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools for other fund types. The use case is inferred from the noun phrase, not explicitly stated.
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?
Annotations already indicate a read-only, idempotent operation. The description adds useful context beyond annotations, such as the date availability constraint (start from 20231110) and the return type as pandas.DataFrame. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a standard docstring format with title, URL, and parameter documentation. It is front-loaded with the title and each line serves a purpose, though the URL line adds minor extra noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 includes the source URL, date availability, and return type. It lacks details about DataFrame columns or behavior when parameters are omitted, but the tool is straightforward and the annotations cover safety aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description must compensate. It provides basic meanings for both parameters: date is the start date with data availability noted, and vars_list is a list of commodity codes. However, it does not clarify optionality, accepted code formats, or the ambiguity of 'start date' possibly implying a range rather than a single date.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Guangzhou Futures Exchange daily trading position ranking data, with a specific source URL and return type. It distinguishes from sibling tools by explicitly naming GFEX, unlike futures_dce_position_rank for DCE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for GFEX daily position rankings and notes that data is available only from 20231110. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral traits beyond the return type (DataFrame) and a source URL, which doesn't disclose 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three lines), but it repeats the same phrase '深证100ETF 期权波动率指数 QVIX' twice. It could be more concise, but it's not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only index data retriever, the description provides the resource, return type, and source URL. It lacks details about the DataFrame columns, but given the simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema fully covers everything. The description doesn't need to explain parameters, and the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Shenzhen 100 ETF options volatility index QVIX) and implies retrieval via ':return:'. It distinguishes from sibling QVIX tools (e.g., 300ETF, 50ETF) by the specific '100ETF' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is specifically for the 100ETF QVIX index. It doesn't explicitly state alternatives or exclusions, but the name and description make the intended use obvious.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable context: the data range from 20000801 to the present, source URLs, and the return type. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, containing the key purpose, data range, source links, and return type. It is structured like a docstring, though the URLs add some clutter. It earns its place without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description is complete: it specifies what data is returned, the time period, and the return format (pandas.Series). No output schema exists, so the explicit return type is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description does not need to add parameter meaning, and the schema coverage is effectively 100% with no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '印度利率决议报告' (India interest rate decision report) and specifies the data range and return type. It distinguishes from sibling tools by explicitly naming India and providing the return value format (今值/current value in %).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for India interest rate data with the date range and source links, but it does not explicitly state when to use it over alternatives like other macro_bank_* tools. No exclusions 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the exact data source URLs and the date coverage, which is useful behavioral context beyond the annotations. It does not discuss rate limits or error behavior, but for a simple read-only data fetch this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core statement about LME position reports and the date range. It includes two source URLs and return-type annotations, which are slightly redundant but not excessive. The structure is clear and economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool, the description provides sufficient context: it names the data source, specifies the date range, and indicates the return type (DataFrame). It does not list DataFrame columns, but the topic is self-explanatory and the source URLs allow further investigation. The description is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and there is nothing to explain. Per the rubric, a baseline of 4 is appropriate when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides LME (London Metal Exchange) position/holding reports, with a specific data range from 20151022 to present. It includes source URLs, which reinforces the resource type. It distinguishes from siblings like macro_euro_lme_stock by using '持仓' (position) rather than 'stock' (inventory).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indirectly implies usage for retrieving LME position data, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria or mention sibling tools. The purpose is clear enough that an agent can infer its usage, but explicit guidance is missing.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the return type (pandas Series with current value in 10k barrels) and the data range, which are useful context beyond what annotations provide. It does not disclose update frequency or limitations, but for a simple read-only fetch this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title-like phrase, two reference URLs, and return type info. It is front-loaded with the report name and data range, with no redundant wording. The URLs are extra but not excessive for a data source reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless macro data tool, the description covers the essential aspects: the report type, historical range, and return format. With annotations providing safety context and no output schema needed, this is reasonably complete. The only gap is update frequency, which is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, 0 params scores a baseline of 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides the US API crude oil inventory report, specifies the data range from 20120328 to present, and describes the return as the current value in ten-thousand barrels as a pandas Series. This is a specific verb+resource that distinguishes it from sibling tools like macro_usa_eia_crude_rate by explicitly naming 'API'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus other macro data tools, though the name and content imply it is for US API crude oil inventory data. No alternatives or exclusions are mentioned, so usage context is implied rather than clearly guided.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds specific behavioral context beyond annotations: it can only retrieve data for the full week containing the given date, and the return type is a pandas DataFrame. This is valuable for setting expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and uses a structured docstring format (:param, :type, :return, :rtype), making it easy to parse. The URL is slightly redundant but adds provenance; the title/return duplication is minor. Overall, it is appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is fairly complete: it covers the source, the parameter's meaning, and the return type. It lacks example usage or DataFrame column details, but the default value and URL provide enough context for basic invocation. Annotations enrich the picture further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the 'date' parameter, so the description carries the full burden. The description explains that the date determines the complete week being queried ('只能获取指定日期所在完整周的票房数据') and specifies the type as str, which gives the parameter clear semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves weekly movie box office data ('单周票房'), names the source URL, and specifies the key parameter constraint. It distinguishes itself from sibling movie_boxoffice tools (daily, monthly, yearly) by its weekly 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for weekly box office data through its title and param description, but it does not explicitly state when to use this tool versus sibling tools like movie_boxoffice_daily or movie_boxoffice_monthly. The constraint that the date must fall within the target week is a useful usage guideline, but no alternatives or exclusions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that it returns daily-frequency data as a pandas.DataFrame, which is useful context, but it does not describe DataFrame columns, potential errors, pagination, or data source limitations. Given the annotation coverage, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a clear title line followed by parameter and return documentation. It is structured and does not contain filler, though the docstring formatting with :param/:return lines is slightly more than necessary for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what data is returned. It only states '日频率数据' (daily-frequency data) and DataFrame, leaving the columns and scope (e.g., date range) unspecified. It adequately covers the purpose and parameter, but the return contents are vague, which is a notable gap for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a type and default for symbol with no description, so the description must compensate. It does so effectively by explaining that symbol includes call/put identifiers and can be obtained from option_cffex_hs300_spot_sina, giving the agent actionable guidance for filling the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '新浪财经-中金所-沪深300指数-指定合约-日频行情' (Sina Finance-CFFEX-CSI 300-specified contract-daily quotes), identifying the specific resource, action (fetch quotes), and frequency. This distinguishes it from siblings like option_cffex_hs300_spot_sina (spot) and option_cffex_sz50_daily_sina (different underlying index).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by explaining the symbol is a specific contract code and directs users to ak.option_cffex_hs300_spot_sina to obtain valid symbols. It clearly implies this tool is for daily-frequency data for HS300 contracts, but it does not explicitly state when-not-to-use or name alternative tools for other frequencies/indices.
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?
Annotations already provide readOnly, idempotent, and non-destructive hints, lowering the burden. The description adds useful context beyond annotations: it specifies that the first returned contract is the main contract and that coverage currently includes only HS300 and CSI1000 indices. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key purpose. However, it includes some redundancy (repeating '所有合约' multiple times) and a slightly confusing sentence about current coverage. Overall, it is concise but could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides sufficient context: it identifies the data source, market, index, and the meaning of the first element. It does not describe the structure of the returned dict, but that is not necessary for tool selection given the simple nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter details. The baseline for no parameters is 4, and the description correctly omits irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns all contracts for the HS300 index from CFFEX via Sina Finance, and specifically notes that the first contract is the main contract. This distinguishes it from sibling tools like option_cffex_hs300_daily_sina and option_cffex_hs300_spot_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the index (HS300) and noting current coverage, but it does not explicitly state when to use this vs. alternative list tools (e.g., option_cffex_zz1000_list_sina) or provide exclusions. Usage context is only inferred from the tool name and the coverage note.
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 already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that the data source is Eastmoney and the return type is pandas.DataFrame, but it does not disclose other behavioral traits such as data freshness, rate limits, or handling of invalid symbols. With annotations present, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, including a title, source URL, parameter documentation, and return type. Every line provides useful information without redundancy. 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description covers the source, parameter semantics, and return type effectively. However, it does not detail the DataFrame columns or data granularity beyond 'minute frequency', which would be helpful but not critical given the tool's straightforward nature and strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and a default value, with 0% schema description coverage. The description compensates fully by explaining that 'symbol' is the option code and instructs the caller to obtain it via option_current_em(), which is meaningful guidance beyond the schema. The default value 'MO2404-P-4450' also serves as a format example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides option market minute data ('期权市场-分时行情') and returns '指定期权的分钟频率数据' (minute frequency data for the specified option). It specifies the resource and action, though it does not explicitly differentiate from sibling option minute tools like option_sse_minute_sina or option_finance_minute_sina.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on how to obtain the symbol parameter ('通过调用 ak.option_current_em() 获取'), which is useful for correct invocation. It implies this tool is for minute-level option data from Eastmoney but does not mention when to use alternatives or provide exclusions, so it falls short of a 5.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing it as a safe read operation. The description adds valuable behavioral context beyond annotations by warning that repeated executions will cause Sina to temporarily ban the IP, and it specifies the data source and return type (pandas.DataFrame).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence (with a semicolon) to convey the tool's purpose, the IP warning, and a reference URL. The docstring-style return type is also present. Every element earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description states that the return is a pandas.DataFrame containing real-time data for all B-shares. It also includes a critical behavioral warning about rate limiting and a direct source link. Given the tool's simplicity (no parameters), this is complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, and the schema confirms this with 100% coverage. With no parameters to document, the description is not expected to add parameter details. The description correctly explains the return value and data scope, which is sufficient given the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing real-time quotes for all B-shares from Sina Finance ('新浪财经-所有 B 股的实时行情数据'). The verb is implicit but the resource is specific, and it distinguishes from sibling tools like stock_zh_a_spot_em or stock_zh_b_daily by focusing on B-share spot 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does include a warning about repeated execution leading to IP bans, which is a usage constraint but not a comparison to sibling tools or scenarios for selection.
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 already cover read-only, idempotent, and non-destructive behavior. The description adds the source URL and return type (pandas.DataFrame), but does not disclose the structure of the returned ranking data or any error/limitation behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, with a title, URL, and param/return sections. The URL adds useful provenance, though it could be omitted for brevity. Overall, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool, the description covers the parameter semantics and return type adequately. It lacks a description of the returned columns or the fixed descending order, but the title and source URL provide sufficient context for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully documents the sole parameter 'date' with four distinct format options and their meanings. This completely compensates for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is an AQI ranking for 168 cities from the Zhenqi Net (真气网-168 城市 AQI 排行榜). It specifies the data type returned (air quality ranking data) and the source URL, making it distinct from sibling air quality tools that focus on historical data or specific regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on how to use the date parameter with examples for current, daily, monthly, and yearly rankings. It does not, however, mention alternatives or when not to use this tool relative to other air quality functions, so it falls short of a 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it returns a pandas.DataFrame, but does not disclose other behavioral aspects like real-time status or whether it returns the full universe of instruments. Minimal extra context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact: a title line, a source URL, and return type documentation. It is front-loaded and contains no filler words, making it easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is largely sufficient: it names the data source, market segment, and return type. However, it omits any details about columns or data frequency, which would be useful for an agent to fully understand the returned data without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and the description does not need to explain any parameters—it remains appropriately silent on that front.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning Shanghai Exchange pledged repo data from East Money, with a specific URL and return type. The name and description distinguish it from the sibling bond_sz_buy_back_em (Shenzhen) and historical buyback variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for Shanghai pledged repo from a specific East Money page. It does not explicitly name alternatives or exclusions, but the 'sh' in the name and the explicit '上证' make the Shanghai scope and primary use case obvious.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable context beyond annotations: the risk of IP ban with large-scale scraping, the source URL, and the return type (pandas DataFrame), which are not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a concise first sentence stating the purpose, followed by a URL and parameter/return documentation. It is slightly longer than strictly necessary due to the URL, but the essential information is front-loaded and there is no excess verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 is fairly complete: it states the data type returned (daily K-line), the return type (pandas DataFrame), and includes a usage warning. It does not enumerate DataFrame columns, but that is not essential for a straightforward historical data retrieval tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by explaining that 'symbol' is the Shanghai/Shenzhen convertible bond code, its type as 'str', and providing an example ('sh010107'). This gives an agent precisely the information needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves historical market data for Shanghai/Shenzhen convertible bonds, specifically daily K-line data for a given bond code. This distinguishes it from sibling tools like bond_zh_hs_cov_min (minute data) and bond_zh_hs_cov_spot (spot data), and specifies the return type as a pandas DataFrame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning that heavy scraping can lead to an IP ban, providing caution about usage frequency. However, it does not explicitly compare with alternative tools or state when to prefer this tool over others, leaving usage context implied by the tool's daily historical nature.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description supplements this by specifying the return type (pandas.DataFrame) and the source URL, adding behavioral context beyond the annotations. It does not disclose data freshness or rate limits, but those are minor for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing a title, URL, parameter documentation, and return type in a compact format. It is efficiently structured and front-loaded with the tool name, though it lacks a brief example or additional formatting that would make it even clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter) and rich annotations, the description covers the essential facts: what the tool does, where data comes from, parameter values, and return type. It could be more complete with an example output or column details, but for a simple list retrieval tool it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'symbol' parameter (0% coverage), but the description fully compensates by listing all valid enum values ('热玩榜', '热门榜', '新品榜', '预约榜', '热卖榜'). This is essential since the schema lacks an enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching TapTap game rankings ('TapTap-游戏榜单') with the URL provided, and specifies the resource type (榜单/rankings). It distinguishes itself from the many financial/macro siblings by being solely about gaming platform 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining TapTap game rankings but does not explicitly state when to use it over alternatives or provide any exclusion criteria. The URL and list types give context, but there is no explicit guidance on selecting this tool.
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?
Annotations already declare safe read-only, idempotent behavior. The description adds the return type (pandas.DataFrame), the source URL, and clarifies that the data corresponds to a single trading day. It does not mention rate limits or edge cases, but the core behavior is transparent beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with Chinese title, source URL, parameter/type, and return/type information. It is structured and each line contributes meaning without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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. The description specifies the return type and general content, which is sufficient given the lack of an output schema. It does not enumerate columns or discuss missing data, but the low complexity and clear return description make it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a 'date' field with a default value and no description. The description compensates fully by explaining it is a trading day in YYYYMMDD format (e.g., 20200416) and specifying that the return contains per-variety market data for that date.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Dalian Commodity Exchange daily trading data, provides the source URL, and states it returns per-variety market data for a specific trading date. It distinguishes this from sibling daily tools for other exchanges (e.g., get_cffex_daily, get_czce_daily) and from DCE-specific rank tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving DCE daily data by date, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Given the sibling list contains other exchange daily tools, the context makes the intended use clear, but no explicit guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it explains that SHFE and CFFEX variety rankings are aggregated from contract rankings and thus not true rankings, that DCE lacks contract rankings, and it details default date and commodity behavior. These caveats are critical for correctly interpreting the data and go well beyond the readOnly/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with its purpose, followed by critical caveats, parameter documentation, and a return schema. It is somewhat lengthy but each section serves a purpose, and the docstring-style format is standard and scannable. It earns a 4 rather than 5 because the return schema section is truncated and includes unnecessary duplication of column types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core caveats, parameter semantics, and a partial return schema. However, it does not list all expected output columns (it stops at vol_top10, missing top15/top20 columns), does not explicitly name all four exchanges, and lacks error/empty-data behavior. Given the tool's complexity and absent output schema, this is a minor but notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden of parameter semantics. It defines start_day and end_day formats (YYYY-MM-DD, YYYYMMDD, datetime.date), defaults to today when empty, and describes vars_list as a list of contract varieties with example ['RB','AL'], defaulting to all commodities when empty. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it collects top 5/10/15/20 member position ranking data from four futures exchanges, with specific notes about aggregation rules. However, it does not differentiate from sibling tools like get_rank_sum or futures_dce_position_rank, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for daily futures position ranking queries by describing what data it returns, but it provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions. The notes about data aggregation are more about interpretation than tool selection, so the 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral detail beyond this: it specifies the return type (pandas.DataFrame), the 'ry' column, and whether the index is date or variety, and reveals that 'symbol' mode returns closing prices. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized as a docstring with :param and :return labels, front-loading the core type_method behavior. Each line is informative and there is no fluff; while dense, the length is justified by the need to document five parameters at zero schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and the schema lacks descriptions, the description provides a compact output definition and mode explanations, making the tool usable. It could be improved by explicitly mapping which parameters are relevant per type_method and mentioning defaults (visible in schema), but the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of parameter semantics. It documents type_method with three enumerated behaviors, gives var examples ('RB', 'AL'), and provides date formats (YYYYMMDD) for date, start_day, and end_day. It lacks explicit guidance on how start_day/end_day combine with date/type_method, but overall it compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (展期收益率/roll yield data) and provides three explicit query modes via type_method, each with a specific output (closing prices, cross-sectional roll yields, time series). However, it does not distinguish this tool from the similarly named sibling get_roll_yield, so purpose is clear but sibling differentiation is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete scenarios for each type_method value ('symbol' for all contracts of a variety on a date, 'var' for cross-section across varieties, 'date' for time series per variety), which tells an agent when to choose each mode. It does not explicitly name alternatives or exclusions relative to sibling tools, so it falls short of a full when/when-not statement.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable context beyond annotations: the data range, a source URL, and the return type (pandas.Series with values in %). This provides operational expectations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only essential information: report name, data range, source URL, and return type. No filler or redundant text; every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with annotations, the description provides enough context: data range, source, and return type. It does not include an output schema, but the return type is stated. It lacks nuanced details like frequency or timezone, but the tool is simple enough that this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the baseline is 4. The description adds no parameter details but clarifies the return semantics (current value in %) and data range, which is sufficient given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the US Federal Reserve interest rate decision report, specifies the data range (19820927 to present), and states the return format (pandas.Series of current values in %). This distinguishes it from sibling tools for other countries' interest rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it covers the Fed's interest rate decisions, but it does not explicitly state when to use this over alternatives or mention exclusions. There is no direct comparison to sibling tools like macro_bank_euro_interest_rate, so guidance is only implicit via the name and description.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the data source (East Money) and the return type (pandas.DataFrame), which are useful behavioral details beyond the annotations. It does not describe data granularity or date range, but for a zero-param read-only tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the title, source URL, return label, and return type each on their own line. Every line provides useful information without verbosity, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, read-only, clear annotations), the description provides sufficient context: it identifies the data source, the specific indicator, and the return type. While it could mention whether the data is historical or current, the URL and return type 'pandas.DataFrame' imply a tabular dataset, which is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline for parameter semantics is 4. The description adds no parameter information, but none is needed. The schema coverage for parameters is effectively 100% since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it retrieves Canada new housing starts data from East Money (东方财富) economic data. The title and return type (`:return: 新屋开工`, `:rtype: pandas.DataFrame`) specify the exact indicator and output format, distinguishing it from sibling macro_canada_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the data source (URL) and confirms it is a data retrieval operation, but does not explicitly state when to use this tool over alternatives. The usage is implied by the name and category, but no exclusions or alternative recommendations are given.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds useful context: the exact data range, the return type (pandas.DataFrame), and the source URL. This goes beyond what annotations provide without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of three short lines: the report title and date range, the source URL, and the return type. Every line adds value, and there is no redundant or extraneous wording. It is efficiently structured for quick consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the return type and data range, which is essential. It does not list specific DataFrame columns or clarify whether all historical data is returned or just the latest week, but given the zero-parameter, simple fetch nature of the tool, the provided information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the empty schema is 100% covered by definition. The description adds relevant non-parameter information (return type and source), which is appropriate for a zero-parameter tool. The baseline of 4 applies here, and the description does not detract from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the Baker Hughes drilling report (rig count) with a specific data range (20080317 to present) and source URL. It effectively distinguishes this from sibling macro_* tools by naming the unique data source and metric (rig count).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context via the title and data range, but it does not explicitly state when to use this tool versus alternatives. There are no explicit exclusions or references to other tools, so the guidance is implicit rather than prescriptive.
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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: the return type is a dict and the first contract is the main contract, which helps the agent understand the output ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise lines, front-loaded with the main purpose, includes scope (which indices are covered) and return type, with no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides the data source, scope, ordering behavior, and return type. It does not describe the dict structure, which would be helpful for interpreting results, but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the return value and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists all SSE 50 index option contracts from Sina Finance-CFFEX, and notes that the first returned contract is the main contract. This specific verb-resource pairing clearly distinguishes it from sibling tools for daily or spot data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that Sina Finance-CFFEX currently covers three indices (SSE 50, CSI 300, CSI 1000), implying which sibling list tools to use for other indices. However, it does not explicitly state when to prefer this tool over the daily or spot variants, so the guidance remains implicit.
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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds the return type (pandas.DataFrame) and enumerates valid symbol choices, but does not disclose behavioral nuances like date format expectations, data availability limits, or potential network dependencies. Given the annotations, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise docstring: title, source URL, parameter definitions with types, and return type. No fluff, each line earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read-only data fetch with strong annotations, the description covers the essential semantics: what data is returned, where from, and what the parameters mean. It could explicitly state the date format (YYYYMMDD) and clarify that the data is historical/daily, but the schema defaults and title cover most needs. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It provides meaning for both parameters: trade_date is '交易日' (trading day) and symbol lists all 13 valid choices. It lacks an explicit format for trade_date, but the default '20250418' in schema implies YYYYMMDD. This meaningfully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '上海期货交易所-期权-日频行情数据' which identifies the resource (SHFE options daily market data) and the operation (data retrieval). The exchange is explicit in both the name and description, distinguishing it from sibling option_hist_czce, option_hist_dce, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for SHFE options daily data by naming the exchange and providing a source URL. It distinguishes itself from other option_hist_* tools via the exchange, but does not explicitly state when not to use this tool or mention alternatives, so lacks an explicit exclusion.
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 already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is fully covered. The description adds that it returns a pandas.DataFrame and includes a source URL, which is helpful context. However, it doesn't disclose potential rate limits, error behavior, or what specific fields appear in the DataFrame, leaving some behavioral ambiguity beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a title line, a source URL, then a docstring-style param/return block. Every sentence adds value (source for verification, param meaning, return type), and there is no fluff or repetition of schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional param, no output schema), and the description covers its core purpose, input meaning, and return type. However, it stops at '实时行情' without listing typical columns (e.g., 最新价, 涨跌幅) that would fully inform an agent about the output. Since there is no output schema, the description ideally should enumerate these fields to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for 'symbol', yet the description explicitly defines it as '板块名称 or 东财板块代码' (sector name or Eastmoney code) and specifies the type 'str'. It also indicates the return type. With 0% schema coverage, this fully compensates for the missing structured documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '东方财富网-沪深板块-行业板块-实时行情' (Eastmoney Shanghai/Shenzhen industry sector real-time quotes), specifying the verb (get real-time quotes), resource (industry sectors on SSE/SZSE), and scope. It includes a source URL and distinguishes itself from siblings like stock_board_industry_hist_em (historical) and stock_board_industry_cons_em (constituents) by emphasizing '实时行情'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: to get real-time quotes for an industry sector, provide either a board name or Eastmoney code as the 'symbol' parameter. The default value '小金属' gives an example. It does not explicitly mention alternatives or exclusions, but the '实时行情' wording makes it obvious when this tool is appropriate relative to historical or constituent-focused siblings.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral context: the date parameter format (quarter-end dates starting from 20100331) and the return type (pandas DataFrame). These details go beyond the annotations and help the agent understand 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the title, followed by a URL and parameter/return documentation. It uses a docstring-like structure that is efficient, though the URL and formatting could be slightly cleaner. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description is relatively complete. It explains the parameter semantics, return type, and data source. It lacks column details and error behavior, but these are not critical for this simple data-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining the date parameter: allowed values are specific quarter-end dates (e.g., 20200331, 20200630), the format is YYYYMMDD, and it starts from 20100331. This adds significant meaning beyond the bare schema, which only provides a default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the income statement (利润表) from East Money's data center for annual/quarterly reports, with a specific URL and return type. This distinguishes it from sibling tools like stock_zcfz_em (balance sheet) and stock_xjll_em (cash flow statement) by specifying the exact financial statement type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context via the title and parameter description but does not explicitly state when to use this tool versus alternatives. It provides no exclusions or alternative tool references, making usage guidance 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds value by stating the return type (pandas.DataFrame) and the official source URL, which clarifies the data origin and output 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured as a docstring, including the source URL, parameter documentation, and return type. Every element serves a purpose without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential details: data source, parameter meaning, and return type. It does not enumerate the columns of the summary DataFrame, but this is not critical given the tool's simplicity and the presence of sibling tools for more specific margin data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It does provide a docstring for the 'date' parameter ('交易日', meaning trading day) and its type, which gives semantic meaning. However, it does not specify the date format, though the default '20240411' in the schema hints at it. This is helpful but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves SZSE margin trading summary data (融资融券汇总), with a specific source URL. The tool name and description together distinguish it from sibling tools like stock_margin_sse and stock_margin_detail_szse by exchange and summary-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for querying Shenzhen Stock Exchange margin summary data for a given trading day. However, it does not explicitly mention alternatives or when not to use it, though the differentiation is apparent from the tool name and siblings.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the source URL and the return type (pandas.DataFrame), which is useful context. It does not contradict annotations and provides some behavioral information beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly three lines, specifying the source, the return content, and the return type. Every sentence earns its place with no unnecessary information, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description covers the essential purpose, return type, and source. It could be improved by explicitly stating that it is for the pink sheet segment to avoid confusion with broader US stock tools, but it is still reasonably complete for a 0-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to add parameter semantics. The schema coverage is 100% vacuously, and the description appropriately includes no parameter information. This aligns with the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the resource as '粉单市场实时行情' (pink sheet market real-time quotes) and provides the source URL from East Money, distinguishing it from sibling tools like stock_us_spot_em by specifying the pink sheet market segment. The verb is implicit but clear: it returns real-time quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching pink sheet real-time quotes but does not provide explicit when-to-use or alternative guidance. It lacks exclusions or comparisons with sibling tools, so it is at the implied usage level.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is fully covered. The description adds the return type (pandas.DataFrame) and source URL, but does not disclose rate limits, columns, or other behavioral details. It provides minimal extra value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only three short lines: purpose, source URL, and return type. It is front-loaded with the essential purpose and contains no filler, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is sufficiently complete: it names the data provider, asset class, and return type. It does not list DataFrame columns, but that is a minor gap given the simplicity of the tool. The URL accidentally points to the A-share board (hs_a_board), which could cause slight confusion but does not invalidate the stated purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema has 100% coverage (nothing to document). The description does not need to add parameter semantics; the baseline of 4 applies because no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves real-time B-share quotes from Eastmoney (东方财富网). The name suffix '_em' further distinguishes it from the sibling tool 'stock_zh_b_spot', which is not Eastmoney-specific. The purpose is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context of the data source and asset class (B-shares), implying when to use it. However, it does not explicitly state exclusions or alternative tools, such as the difference from stock_zh_b_spot, but the '_em' suffix and clear context are sufficient for a zero-parameter simple tool.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: data starts from 20100416, updates around 16:30 on trading days, and returns a pandas DataFrame. It does not mention auth or error behavior, but these are less critical given the read-only, idempotent nature already annotated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with title, URL, a usage note, parameter docs, return type, and field definitions. It is front-loaded with the purpose, and the later sections are clearly labeled. Though somewhat long, every section serves a purpose for a data-heavy tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates fully by listing all return fields with types and Chinese labels. Parameters are explained with formats and defaults, data source and cadence are given, and the dual-ranking note addresses a potential source of confusion. This is sufficient for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, so the description must carry the full parameter semantics. It thoroughly documents both parameters: date accepts multiple formats (YYYY-MM-DD, YYYYMMDD, datetime.date) and defaults to today; vars_list takes a list of contract codes like RB/AL and defaults to all commodities. It also explains the data timeframe and update frequency, significantly enriching the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the CFFEX top 20 member position ranking data, provides the source URL, and notes that both product and underlying rankings are published. This distinguishes it from sibling rank table tools for other exchanges (DCE, SHFE, CZCE) by naming CFFEX specifically, but it lacks an explicit verb phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage context: parameter formats and defaults (empty date means today, empty vars_list means all commodities), data availability starting from 20100416, and the daily update time. The note about the exchange publishing both product and underlying rankings helps prevent misinterpretation, though it does not explicitly mention when not to use this tool or compare it with sibling exchange rank tools.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context: accepted date formats, default-to-today behavior, the return type as pandas.DataFrame, and a URL pointing to the source. It does not mention rate limits or failure modes, but for a read-only retrieval tool these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clearly labeled sections (source URL, note, param, return, return format) and is information-dense. It is somewhat long, but every section adds necessary detail; the field table is valuable given the absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal input schema, the description provides a complete field-by-field breakdown of the returned DataFrame, explains the date parameter thoroughly, and notes the exchange-specific behavior (both variety and underlying rankings). This is fully sufficient for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'date' with no further explanation (coverage 0%). The description fully compensates by specifying accepted formats (YYYY-MM-DD, YYYYMMDD, datetime.date) and the default behavior (today if empty), which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Zhengzhou Commodity Exchange (CZCE) top 20 member position ranking data, with a specific resource and verb. It distinguishes from sibling rank-table tools (e.g., get_dce_rank_table, get_cffex_rank_table) via the explicit '郑州商品交易所' (CZCE) and top-20 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied: the tool is for CZCE ranking data, and the note about both variety and underlying rankings clarifies data granularity. However, it does not explicitly state when to use this tool versus alternatives like get_rank_sum or other exchange rank tables, and no exclusions or alternative tool names are mentioned.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds valuable context such as the data range (19700101-至今), the source URL, and the return type (pandas.Series), supplementing the annotations with concrete behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, followed by a useful source URL. The docstring lines ('获取美国失业率报告' and 'pandas.Series') add some redundancy, but the overall size is appropriate and every substantive detail (range, source, return type) is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only data retrieval tool with no output schema, the description adequately covers the key aspects: what data is provided (US unemployment rate), the historical period, the data source, and the return type as pandas.Series. It does not specify the data frequency (e.g., monthly), but this is a minor gap for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema. Since there are no parameters to describe, the baseline for zero-parameter tools is 4. The description does not need to explain parameter semantics, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '美国失业率报告' (US unemployment rate report) with a specific data range from 19700101 to present, and includes a source URL. The verb '获取' and resource are explicit, distinguishing it from other macro_usa_* sibling tools by its specific economic indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it returns the US unemployment rate report for the range 19700101-present, sourced from a specified URL. It does not explicitly mention alternatives or exclusions, but the tool name and subject matter make the use case clear among sibling tools, especially compared to other unemployment rate tools for different countries.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by stating it returns real-time ('实时') call/put market data and provides the data source URL. It does not describe error handling or data freshness, but given the safety profile is covered by annotations, this is above-average value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a title, source URL, parameter detail, and return type. Every element earns its place; no redundant or missing critical information. It is cleanly structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description tells the user the return type (pandas.DataFrame) and the general content (call/put quotes), but it does not enumerate DataFrame columns or clarify that the symbol is optional (schema default 'mo2208'). The absence of an output schema increases the need for such details, though the tool's simplicity partially mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `symbol` has no schema description (0% coverage), but the description compensates thoroughly by explaining it is a contract code and directing users to the list function for valid values. This provides actionable semantic meaning beyond the bare schema, including a lookup method.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it provides '中金所-中证 1000 指数-指定合约-实时行情' (CFFEX CSI 1000 index specified-contract real-time quotes) and further specifies the return as call/put real-time quotes. This clearly identifies the tool's unique function and distinguishes it from sibling tools like daily snapshots or list functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one cross-reference: '用 option_cffex_zz1000_list_sina 函数查看' to find the symbol code. However, it does not explicitly state when to use this tool vs. alternatives such as daily data or other index options (e.g., HS300). Usage context is implied by '实时行情' but not explicitly contrasted with siblings.
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?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds behavioral context by stating that volume is standardized to shares and amount to yuan, and by listing adjust options. It does not mention rate limits or data delays, but the unit normalization is a notable addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured docstring: a title line, a URL example, and parameter/return definitions. Every line is informative, non-redundant, and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema, the description covers the main inputs, return type, and unit normalization, which is sufficient for basic usage. However, it does not specify the expected date format (e.g., YYYYMMDD) or how missing data is handled, leaving minor gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates with a complete docstring for all five parameters, including symbol format, date semantics, adjust choices with Chinese labels, and timeout constraints. This provides significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with "腾讯证券-日频-股票历史数据" (Tencent Securities daily stock historical data), which clearly identifies the resource, source, and frequency. The docstring specifies it returns historical quote data as a pandas DataFrame, distinguishing it from spot or intraday tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for daily historical stock data from Tencent, but provides no explicit when-to-use or alternative comparisons. It does not mention when not to use this tool or how it differs from related tools like stock_zh_a_hist or stock_zh_a_daily.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds the key behavioral trait of data being limited to the current trading day and specifies the return type (pandas.DataFrame), which complements the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose and limitation. It includes a source URL and docstring-style parameter/return info, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 the description explains the return type and scope. However, it does not detail DataFrame columns or error behavior, which slightly reduces completeness for a tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter with no description. The description defines symbol as '期权代码' (option code) with type str, providing essential meaning. With schema coverage at 0%, this compensation is valuable, though it lacks examples or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves minute data for a specified option on the current trading day, explicitly noting historical data is unavailable. This distinguishes it from sibling tools like option_sse_daily_sina (daily data) and option_sse_spot_price_sina (spot price).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a limitation ('只能获取当前交易日的数据, 不能获取历史分钟数据'), telling the agent not to use it for historical data. However, it does not name alternative tools for historical minute data, so it lacks explicit alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read nature is clear. The description adds valuable behavioral context beyond annotations: all data is '前复权' (forward-adjusted), different websites use different adjustment methods, and the data source is Tencent Securities. This helps the agent understand adjustment implications without being told explicitly in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a title, rationale, warning, URL, and parameter docs. Each sentence serves a purpose. There is slight redundancy between the title and the first sentence, but overall it remains efficient and scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read-only tool with no output schema, the description covers the source (Tencent Securities), adjustment behavior, parameter formats, and provides a reference URL. It states the return type as a pandas DataFrame, but does not enumerate columns; however, that gap is minor given the tool's simplicity and the presence of a link for more details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description provides comprehensive parameter documentation in the docstring: symbol is a stock/index code with market identifier, start_date is in YYYYMMDD format and defaults to the earliest date when empty, and end_date similarly defaults to the current date. This fully compensates for the lack of schema descriptions and gives the agent precise input formatting guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching daily-frequency historical data for stocks or indices from Tencent Securities, with a specific verb+resource structure. It explicitly distinguishes itself as a supplement to ak.stock_zh_index_daily() for cases where Sina data is missing, making it easy to understand what this tool does relative to 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: it serves as a fallback for missing index data on Sina, as stated in '作为 ak.stock_zh_index_daily() 的补充, 因为在新浪中有部分指数数据缺失'. It also warns that data is forward-adjusted and should not be mixed with other sources, which is important usage guidance. It does not explicitly enumerate alternatives, but the referenced complement function serves that role.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the IP-ban warning (rate limiting) and the return type as pandas.DataFrame. It does not mention pagination or other side effects, but for a read-only historical data tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, front-loading the main purpose and then providing param details. It has a slightly messy structure with the title repeated and a URL, but every part is informative. It earns its place without excessive fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two well-documented parameters and a clear return type. The description includes a source URL and a warning about IP bans. It does not detail the exact columns or date range returned, but for a historical data tool of this simplicity, the information is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining both parameters in detail: symbol (带市场标识的股票代码) and adjust (with all variants: default, qfq, hfq, hfq-factor, qfq-factor). This adds significant meaning beyond the bare schema, making the tool easy to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves historical market data for 科创板 (STAR Market) stocks from Sina Finance, using specific verbs and resource scope. It distinguishes from sibling tools like stock_zh_a_daily (A-shares daily) and stock_zh_kcb_spot (spot data) by focusing on historical daily data for STAR Market 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage caution ('大量抓取容易封IP' - large-scale scraping may get IP banned), which is useful guidance. However, it does not explicitly mention when to use this tool versus alternatives or exclude specific cases, so it lacks explicit when/when-not guidance but still gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behaviors: returns previous month's data, only includes countries with available data, and explicitly removes Ecuador from March 2020 onward. It also specifies the return type as pandas.DataFrame, which the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, front-loading the purpose and including only relevant behavioral details. The fix note for Ecuador and the source URL add useful context but slightly reduce structure quality; overall it stays compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: date range, data lag, country filtering, historical fix, source URL, and return type. Since there is no output schema, the specification of a pandas DataFrame return suffices for a no-parameter read-only tool, though column details are not documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds contextual meaning by explaining the data range and return type, though it does not elaborate on parameters (none exist).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the OPEC monthly report with a specific date range (20170118-present). The verb '返回' (returns) and resource specification distinguish it from the many other macro tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context about the data range and the behavioral nuance that the index date corresponds to the previous month's data. However, it does not explicitly specify when to use this tool over alternatives; it is implied by the unique OPEC report scope.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond these by disclosing the dependency on another function to get valid dates and specifying the return type as pandas.DataFrame. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: title, URL, then clearly labeled param and return sections. Every sentence adds value, and there is no redundant or filler content. It is appropriately front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the essential usage: the data source, the prerequisite date function, allowed flag values, and the return type. It falls slightly short by not describing the actual columns or contents of the returned DataFrame under '个股龙虎榜详情', which could help an agent understand the data structure, but overall it is sufficiently complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It explains all three parameters: symbol (股票代码), date (with the critical prerequisite of calling the date tool), and flag (explicit allowed values '买入' and '卖出'). It also provides a date format hint via the default value '20220315'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching individual stock Dragon-Tiger List details from Eastmoney's data center, with the URL example showing the exact page. It distinguishes itself from siblings via '个股' (individual stock) and the specific parameters, making its purpose unambiguous even without an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context by stating that the date parameter must be obtained from the prerequisite function stock_lhb_stock_detail_date_em. It implicitly tells the agent how to use the tool correctly, though it does not explicitly mention when not to use it or contrast with alternatives.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context by specifying the data source and the return type (pandas DataFrame), which goes beyond what annotations provide. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in a docstring format. Every line adds value: source URL, parameter definitions with types, and return type. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description provides all necessary information: source, parameters, and return type. It does not mention error conditions or rate limits, but these are not critical for a basic data retrieval tool. Given the strong annotations and clear parameter documentation, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries the burden. It clearly explains both parameters: symbol is the fund code, and date is the report publication date with explicit allowed formats (xxxx-03-31 etc.). The example URL further illustrates the parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns fund holdings detail data from East Money's data center, with a specific source URL. The name and description distinguish it from similar tools like stock_report_fund_hold by emphasizing '明细' (details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 via its parameter descriptions (symbol and date with specific formats) and the stated return type. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to select it for fund holding detail queries.
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?
Beyond the annotations (readOnlyHint, destructiveHint, etc.), the description reveals a key behavioral trait: if the current month has not ended, values are filled with predictions. It also discloses the return type as pandas.DataFrame, adding useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes the essential behavior, a source URL, and parameter documentation. It is slightly cluttered by the raw URL, but the overall structure is efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description sufficiently explains what the tool returns (a DataFrame of daily sunrise/sunset data for the month) and covers prediction behavior and parameter usage. This makes the tool fully comprehensible for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero description coverage in the input schema, the docstring fully compensates by explaining both parameters: date is described as specifying the month with an example format '20200428', and city is described with input format examples like '北京'. This provides complete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: returning daily sunrise/sunset data for the month containing the provided date, with predicted values for future days. This is specific and distinguishes it from the sibling tool sunrise_daily, which likely handles single-day data. The return type is also specified as a DataFrame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a full month of daily sunrise/sunset data is needed, using the date to select the month. It gives a clear context for use but does not explicitly mention alternatives or exclusions, so it stops short of a 5.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/kevynf/akshare-mcp-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server