stockreport-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific data types (e.g., balance data vs. cash flow data) or market segments (A-shares vs. HK vs. US). However, some overlap exists between similar tools for different markets (e.g., get_balance_data and get_hk_balance_data are conceptually similar but for different exchanges), which could cause minor confusion if an agent doesn't carefully note the market prefix.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with a 'get_' prefix for data retrieval, followed by descriptive nouns (e.g., get_balance_data, get_historical_k_data). The naming is highly predictable, with market-specific tools clearly prefixed (e.g., get_hk_*, get_us_*), making the set easy to navigate.
Tool Count2/5
With 47 tools, the count is excessive for a single server, creating cognitive overload. While the domain (stock reporting across multiple markets) is broad, many tools are near-duplicates across markets (e.g., separate tools for A-share, HK, and US balance data) rather than consolidated, making the surface feel bloated and difficult to manage efficiently.
Completeness4/5
The tool set provides comprehensive coverage for stock data retrieval across A-shares, HK, and US markets, including financial statements, market data, indices, and economic indicators. Minor gaps exist, such as lack of update/delete operations (expected for read-only data) and limited analytical tools beyond basic reports, but the surface supports most common stock analysis workflows effectively.
Average 3.4/5 across 47 of 47 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states it fetches data (implying read-only) and returns a markdown table or error, but lacks critical behavioral details: whether it requires authentication, rate limits, what happens if dates are invalid or out of range, if data is cached, or error handling specifics. The mention of 'error message' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses minimal sentences. Every sentence adds value: the first states purpose, the args clarify parameters, and returns specify output format. It could be slightly more concise by integrating args into the purpose sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 2 parameters with 0% schema coverage, and an output schema exists (implied by 'Returns'), the description is moderately complete. It covers purpose, parameters, and output format, but lacks behavioral context (e.g., error conditions, data freshness) and doesn't fully compensate for the missing schema descriptions, leaving gaps in usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by specifying both parameters as optional and providing format ('YYYY'), which the schema lacks. However, it doesn't explain default values (implied by 'Optional' but not stated), valid year ranges, or what happens if only one date is provided. Baseline 3 is appropriate as it adds some value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches yearly money supply data (M0, M1, M2 year-end balance) within a date range, specifying the resource (money supply data) and scope (yearly, date range). It distinguishes from sibling 'get_money_supply_data_month' by specifying yearly vs. monthly data, but doesn't explicitly contrast with other financial data tools like 'get_balance_data' or 'get_cash_flow_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_money_supply_data_month' for monthly data or other financial data tools. It mentions a date range but doesn't specify default behavior if dates aren't provided or when this tool is preferred over similar data-fetching siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions the return format ('Markdown格式的热门美股列表') but doesn't disclose important behavioral aspects: what criteria define 'popular', whether the list is static or dynamic, how many stocks are returned, whether there's pagination, data freshness, rate limits, or authentication requirements. For a tool with zero annotation coverage, this is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with just two lines: one stating the purpose in Chinese, and one specifying the return format. Both sentences earn their place by providing essential information. However, the structure could be slightly improved by front-loading the English translation or making the purpose statement more immediately accessible to non-Chinese readers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (which should document the return structure), the description doesn't need to explain return values in detail. However, for a tool with zero annotations and many similar sibling tools, the description should provide more context about what 'popular' means and when to use this versus alternatives. The current description is minimally adequate but leaves significant gaps in usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema description coverage is 100%), so the description doesn't need to explain parameters. The baseline for zero parameters is 4, as there's no parameter information to add beyond what the empty schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取热门美股列表' (Get popular US stocks list), which provides a clear verb ('get') and resource ('popular US stocks list'). However, it doesn't differentiate from sibling tools like 'get_all_stock', 'get_hs300_stocks', or 'get_popular_hk_stocks' - it only specifies the geographic focus (US) and popularity filter without explaining what makes stocks 'popular' or how this differs from other listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With many sibling tools that retrieve different stock lists (HS300, SZ50, ZZ500, HK stocks, all stocks), the description offers no context about when this specific 'popular US stocks' list would be preferred over other listing tools or search functions like 'search_us_stocks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format ('Markdown格式的美股指数列表' - Markdown format US stock index list), which adds some behavioral context. However, it doesn't disclose other important traits like whether this is a read-only operation, if it requires authentication, rate limits, or what specific indices are included. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and one specifying the return format. It's appropriately sized for a simple tool with no parameters. However, the structure could be slightly improved by front-loading the return format information more clearly, but it's still efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists (though not provided in context), and no annotations, the description is minimally adequate. It states the purpose and return format, but for a data-fetching tool, it could benefit from more context on what '主要指数' (major indices) includes or example output. With output schema handling return values, the description meets basic needs but has room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). With no parameters, the description doesn't need to add parameter semantics. The baseline for 0 parameters is 4, as there's nothing to compensate for. The description appropriately doesn't discuss parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取美股主要指数信息' (Get US stock market major index information), which provides a clear verb ('获取') and resource ('美股主要指数信息'). However, it doesn't distinguish this tool from sibling tools like 'get_us_sector_performance' or 'get_us_stock_realtime_data', which also provide US market data. The purpose is 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on US market data (e.g., 'get_us_sector_performance', 'get_us_stock_realtime_data'), there is no indication of when this specific tool for indices is appropriate versus other data sources. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions the return format ('Markdown格式' - Markdown format), which adds some value beyond the input schema. However, it doesn't disclose important behavioral traits like whether this is a real-time or historical data source, update frequency, data freshness, rate limits, authentication requirements, or error conditions. For a financial data tool with zero annotation coverage, this represents significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two brief sentences in Chinese and English. The first sentence states the purpose, and the second describes the return format. There's no wasted text or redundancy. However, the structure could be slightly improved by combining the bilingual elements more seamlessly rather than having separate language statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (which should document return values), no parameters, and no annotations, the description provides basic purpose and format information. However, for a financial data retrieval tool with many similar siblings, the description lacks sufficient context about what 'sector performance' specifically means, timeframes covered, or data sources. The presence of an output schema reduces the need to explain return values, but more operational context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters, and it correctly doesn't attempt to do so. The baseline for 0 parameters with complete schema coverage is 4, as there's nothing to compensate for and no misleading information about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取美股行业表现' (Get US stock sector performance), which provides a clear verb ('获取' meaning 'get' or 'retrieve') and resource ('美股行业表现' meaning 'US stock sector performance'). However, it doesn't distinguish this tool from its many siblings that also retrieve various financial data, making it somewhat vague in context. The English translation in the description ('Returns: Markdown格式的行业表现数据') adds some clarification but doesn't fully differentiate purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 50+ sibling tools retrieving various financial data (e.g., get_us_market_indices, get_us_stock_realtime_data, get_stock_industry), there's no indication of when this specific sector performance tool is appropriate versus other market data tools. 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?
No annotations are provided, so the description carries the full burden. It mentions the return format ('Markdown格式的搜索结果') but lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, rate limits, error handling, or how results are structured (e.g., pagination). For a search tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement followed by Args and Returns sections. Every sentence adds value without redundancy. It could be slightly more front-loaded by emphasizing the tool's scope earlier, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it leaves gaps in behavioral transparency and usage context. It's complete enough for basic use but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics: it explains 'keyword' as '搜索关键词 (股票名称或代码)' (search keyword: stock name or code), which clarifies the parameter's purpose. However, schema description coverage is 0%, and the description doesn't compensate fully—it lacks details on keyword format, length limits, or examples. With one parameter and some added meaning, it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '搜索港股股票' (search Hong Kong stocks). It specifies the verb '搜索' (search) and resource '港股股票' (Hong Kong stocks), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_us_stocks' or 'get_popular_hk_stocks', which would be needed for 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_us_stocks' for US stocks or 'get_popular_hk_stocks' for trending stocks, nor does it specify use cases or prerequisites. The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format (Markdown) but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what constitutes a 'search' (e.g., fuzzy matching, exact matches). This is inadequate for a tool with no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The Args/Returns structure is clear, though the use of Chinese text might reduce accessibility for some agents. There's no wasted verbiage, but the formatting could be more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should document return values) and only one parameter, the description is minimally complete. However, with no annotations and sibling tools present, it fails to provide sufficient context about behavioral traits and usage differentiation, making it only adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema. It clarifies that the 'keyword' parameter accepts stock names or codes, which is useful since schema coverage is 0%. However, it doesn't provide examples, format constraints, or guidance on how the search operates (e.g., partial matches, case sensitivity), leaving gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for US stocks using keywords (stock names or codes), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'search_hk_stocks' beyond the 'US' qualifier in the name, missing an opportunity to clarify the regional 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_us_stock_basic_info' or 'search_hk_stocks'. The description lacks context about use cases, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'fetches' data and returns a 'Markdown table with balance sheet data or an error message,' which implies a read-only operation with potential errors. However, it lacks details on permissions, rate limits, data freshness, or what specific metrics (beyond examples like current ratio) are included. For a financial data tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose sentence, followed by 'Args:' and 'Returns:' sections that efficiently document parameters and output. Each sentence adds value without redundancy, though the 'Args:' and 'Returns:' labels are slightly verbose compared to a more integrated approach.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, financial data fetching), no annotations, and an output schema (implied by 'Returns:' but not detailed), the description is partially complete. It covers parameters well and mentions the output format, but lacks behavioral details (e.g., error conditions, data sources). With no annotations and an output schema that likely defines the table structure, the description should do more to explain operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter: 'code' as 'The stock code (e.g., 'sh.600000')', 'year' as 'The 4-digit year (e.g., '2023')', and 'quarter' as 'The quarter (1, 2, 3, or 4)'. This clarifies formats and constraints (e.g., quarter values), compensating fully 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetches quarterly balance sheet / solvency data (e.g., current ratio, debt ratio) for a stock.' It specifies the verb ('fetches'), resource ('balance sheet / solvency data'), and scope ('quarterly', 'for a stock'). However, it doesn't explicitly differentiate from sibling tools like 'get_cash_flow_data' or 'get_profit_data', which likely fetch different financial statement types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'get_cash_flow_data' for cash flow statements, 'get_profit_data' for income statements) or specify scenarios where balance sheet data is preferred. Usage is implied through the description 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format ('Markdown格式的现金流数据表格或错误信息' - Markdown-formatted cash flow data table or error message), which is useful. However, it lacks critical behavioral details: whether this is a read-only operation, potential rate limits, data freshness, error conditions beyond invalid inputs, or if it requires specific permissions. For a data-fetching tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized: a clear purpose statement, followed by Args and Returns sections with bullet-like formatting. Every sentence adds value—no fluff. It could be slightly more front-loaded by moving the return format to the first line, but overall it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (data retrieval with 3 parameters), no annotations, and an output schema exists (implied by 'Returns'), the description is moderately complete. It covers the purpose and parameters well, and the output schema will handle return values. However, it lacks behavioral context (e.g., read-only nature, error handling) and usage guidelines, which are important for a tool in a crowded sibling set. This makes it 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'code' is explained as '港股代码' (Hong Kong stock code) with an example 'hk.00700', 'year' as '4位年份' (4-digit year) with example '2023', and 'quarter' as '季度' (quarter) with allowed values 1-4. This clarifies the purpose and format of all three parameters beyond the bare schema, though it doesn't detail constraints like code validation or quarter integer range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取港股季度现金流数据' (get Hong Kong stock quarterly cash flow data) with specific examples like '经营现金流/营业收入比率' (operating cash flow/revenue ratio). It distinguishes from siblings by specifying '港股' (Hong Kong stocks) and '现金流数据' (cash flow data), differentiating from tools like get_hk_balance_data or get_hk_profit_data. However, it doesn't explicitly contrast with the non-HK sibling get_cash_flow_data, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over get_cash_flow_data (for non-HK stocks) or other HK-specific tools like get_hk_balance_data. There's also no information about prerequisites, such as data availability or authentication needs. Usage is implied by the parameters 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'Markdown格式的成长能力数据表格或错误信息' (Markdown-formatted growth data table or error message), which is useful. However, it doesn't disclose other behavioral traits: whether it's read-only (implied but not explicit), rate limits, authentication needs, data freshness, or what constitutes valid inputs beyond the basic schema. For a data-fetching tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first line states the purpose, followed by clear sections for Args and Returns. Every sentence earns its place, with no redundant information. However, the structure could be slightly improved by integrating the parameter details more seamlessly, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters, no annotations, but has an output schema), the description is partially complete. It covers the purpose, parameters, and return format, but lacks usage guidelines, behavioral context (e.g., error handling, data sources), and differentiation from siblings. The output schema existence means the description needn't detail return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'code' as '港股代码 (如 'hk.00700')' (Hong Kong stock code, e.g., 'hk.00700'), 'year' as '4位年份 (如 '2023')' (4-digit year, e.g., '2023'), and 'quarter' as '季度 (1, 2, 3, 或 4)' (quarter: 1, 2, 3, or 4). This clarifies format and constraints beyond the bare schema, though it doesn't explain edge cases (e.g., invalid codes).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取港股季度成长能力数据 (如同比增长率等)' which translates to 'Get Hong Kong stock quarterly growth capability data (such as year-over-year growth rates, etc.)'. It specifies the verb ('获取' - get), resource ('港股季度成长能力数据' - Hong Kong stock quarterly growth data), and scope ('港股' - Hong Kong stocks). However, it doesn't explicitly distinguish from siblings like 'get_growth_data' (which appears to be for non-HK stocks) or 'get_hk_profit_data' (which focuses on profit rather than growth).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_growth_data' (for non-HK stocks) or 'get_hk_profit_data' (for profit data), nor does it specify prerequisites, exclusions, or contextual triggers. The agent must infer usage from the tool 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool returns 'Markdown格式的K线数据表格' (K-line data table in Markdown format), which is useful output information. However, it doesn't disclose important behavioral aspects like whether there are rate limits, authentication requirements, data freshness, error conditions, or pagination for large date ranges. For a data retrieval tool with no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately concise. It starts with the core purpose, then lists parameters with clear explanations, and ends with return format. Each sentence earns its place, and there's no redundant information. The bilingual format (Chinese purpose, English parameter names) is slightly unconventional but doesn't hinder clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no annotations, but has output schema), the description is minimally adequate. It covers the basic purpose and parameters well, and the output schema existence means it doesn't need to detail return values. However, for a financial data tool with many sibling alternatives and no behavioral annotations, it should provide more context about data sources, limitations, or typical use cases to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial semantic value beyond the input schema, which has 0% description coverage. It explains that 'code' is a Hong Kong stock code with an example ('hk.00700' for Tencent), clarifies date format ('YYYY-MM-DD'), indicates 'frequency' defaults to 'd' (daily), and mentions 'fields' is an optional field list. This compensates well for the schema's lack of descriptions, though it doesn't specify possible frequency values or field options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取港股历史K线数据' (Get Hong Kong stock historical K-line data). It specifies the resource (Hong Kong stocks) and action (get historical K-line data), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_historical_k_data' (which appears to be for non-HK stocks) or 'get_hk_stock_realtime_data' (real-time vs historical), so it doesn't reach 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'get_historical_k_data' for non-HK stocks, 'get_hk_stock_realtime_data' for real-time data, 'get_hk_stock_basic_info' for basic info), there's no indication of when this specific historical K-line tool is appropriate versus other data retrieval tools. The description assumes the user already knows when to fetch historical K-line data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('Markdown格式的运营能力数据表格或错误信息' - Markdown-formatted operational capability data table or error message), which is helpful. However, it doesn't disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or what happens with invalid inputs beyond generic error messages. For a data-fetching tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. It starts with the purpose, then lists parameters with explanations and examples, and ends with the return format. Each sentence earns its place by providing essential information without redundancy. However, it could be slightly more front-loaded by emphasizing the tool's uniqueness relative to siblings, but overall it's efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no annotations, but with an output schema), the description is moderately complete. It covers the purpose, parameters, and return format, which is adequate for basic use. However, it lacks details on behavioral aspects (e.g., error handling, data sources) and doesn't differentiate from sibling tools, which reduces completeness. The presence of an output schema means the description doesn't need to explain return values in depth, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains each parameter: 'code' as '港股代码 (如 'hk.00700')' (Hong Kong stock code, e.g., 'hk.00700'), 'year' as '4位年份 (如 '2023')' (4-digit year, e.g., '2023'), and 'quarter' as '季度 (1, 2, 3, 或 4)' (quarter: 1, 2, 3, or 4). This provides clear examples and constraints (e.g., quarter values), compensating well for the lack of schema descriptions. Since there are 3 parameters and the description covers them all, it merits a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取港股季度运营能力数据 (如周转率等)' which translates to 'Get Hong Kong stock quarterly operational capability data (such as turnover rates, etc.)'. It specifies the verb ('获取' - get), resource ('港股季度运营能力数据' - Hong Kong stock quarterly operational capability data), and provides examples ('如周转率等' - such as turnover rates). However, it doesn't explicitly distinguish itself from sibling tools like 'get_operation_data' or 'get_hk_balance_data', which is why it doesn't achieve 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'get_hk_balance_data', 'get_hk_profit_data', 'get_operation_data'), there's no indication of what makes this tool distinct or when it should be chosen over others. The only implicit context is that it's for Hong Kong stocks and quarterly data, but this doesn't help differentiate it from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool provides '数据驱动的分析报告' (data-driven analysis reports) and mentions return content, but lacks critical behavioral details: whether it requires authentication, has rate limits, how recent the data is, or if it performs calculations versus fetching pre-computed reports. The disclaimer about not being investment advice is helpful context but insufficient for a mutation-free analysis 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately concise. It opens with the core purpose, includes a disclaimer, then clearly documents parameters and returns in labeled sections. Every sentence adds value, with no redundant information. The only minor improvement would be integrating the disclaimer more seamlessly rather than as a separate clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, analysis types), no annotations, but with an output schema that presumably documents the return structure, the description is minimally adequate. It covers parameters well and outlines return content, but lacks behavioral context (data freshness, sources, limitations) that would be important for an analysis tool. The output schema reduces the need to detail return values, but overall completeness is just sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant semantic value beyond the input schema, which has 0% description coverage. It explains that 'code' is a Hong Kong stock code with format example 'hk.00700', and that 'analysis_type' has three specific options ('fundamental', 'technical', 'comprehensive') with a default of 'fundamental'. This compensates well for the schema's lack of descriptions, though it doesn't detail what each analysis type entails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '提供基于数据的港股分析报告' (provides data-driven Hong Kong stock analysis reports). It specifies the resource (Hong Kong stocks) and distinguishes it from general stock analysis tools like 'get_stock_analysis' by focusing on Hong Kong markets. However, it doesn't explicitly differentiate from other Hong Kong-specific tools like 'get_hk_stock_basic_info' or 'get_hk_stock_realtime_data' in terms of analysis depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for Hong Kong stock data (e.g., 'get_hk_balance_data', 'get_hk_profit_data', 'get_hk_stock_basic_info'), there's no indication of whether this tool aggregates data from those sources or serves a different purpose. The disclaimer '而非投资建议' (not investment advice) is useful but doesn't address tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('Markdown格式的基本信息表格' - Markdown-formatted basic info table), which is useful. However, it lacks critical details: whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what 'basic information' entails beyond the example. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and structured with clear sections (Args, Returns). Each sentence adds value: the title states the purpose, and the parameter and return explanations are necessary. There's no fluff, though it could be slightly more front-loaded by integrating the return format into the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers parameters and return format adequately, but lacks behavioral context (e.g., safety, limits) and doesn't leverage the output schema to explain return values more thoroughly. It's minimal but not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains 'code' as a Hong Kong stock code with an example ('hk.00700' for Tencent) and clarifies 'fields' as an optional list of fields. This compensates well for the schema's lack of descriptions, though it doesn't detail possible field values or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取港股基本信息' (Get Hong Kong stock basic information). It specifies the resource (Hong Kong stocks) and verb (get basic information), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_stock_basic_info' or 'get_us_stock_basic_info', which target different markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_stock_basic_info' (for other markets) or 'get_hk_stock_realtime_data' (for real-time vs. basic info), nor does it specify prerequisites or exclusions. Usage is implied by 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool fetches data and returns a markdown table or error, but lacks critical behavioral details: it doesn't specify data sources, update frequency, rate limits, authentication needs, error conditions beyond generic 'error message', or whether the date range is inclusive/exclusive. For a data-fetching tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses minimal sentences. Every sentence adds value: the first states the purpose, the next two document parameters, and the last specifies the return format. It could be slightly more concise by integrating parameter details into a single sentence, but it's efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 optional parameters, no annotations, but has output schema), the description is partially complete. It covers purpose and parameters well, and the output schema likely handles return values, so the description doesn't need to detail the table structure. However, it lacks behavioral context (e.g., data freshness, error specifics) and usage guidelines, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly documents both parameters (start_date, end_date) with format details ('YYYY-MM'), optionality, and their role in defining the date range. This adds significant value beyond the bare schema, though it doesn't explain default behavior when parameters are null or how missing dates are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches monthly money supply data (M0, M1, M2) within a date range, providing a specific verb ('fetches') and resource ('monthly money supply data'). It distinguishes from sibling 'get_money_supply_data_year' by specifying 'monthly' versus 'yearly', but doesn't explicitly differentiate from other data-fetching siblings like 'get_balance_data' or 'get_cash_flow_data' beyond the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_money_supply_data_year' for yearly data or other financial data tools, nor does it specify prerequisites, constraints, or typical use cases beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the return format (Markdown table), it doesn't describe important behavioral aspects like rate limits, authentication requirements, data freshness, error conditions, or whether this is a read-only operation. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured with clear sections for Args and Returns. The purpose statement is front-loaded, and each parameter gets a brief explanation. While efficient, the Chinese-only content might limit accessibility in some contexts, but within its language, it's concise and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no annotations, but with output schema), the description is minimally adequate. It covers parameters well and mentions the return format, but lacks important context about behavioral traits, usage guidelines relative to siblings, and doesn't explain what 'K-line data' specifically entails. The output schema existence reduces the need to detail return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful semantic information for all 5 parameters beyond what the schema offers (which has 0% description coverage). It explains that 'code' represents US stock codes with examples, clarifies date formats, indicates frequency defaults to daily, and mentions fields are optional. This compensates well for the schema's lack of descriptions, though it could provide more detail about valid frequency values or field options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取美股历史K线数据' (Get US stock historical K-line data), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_historical_k_data' or 'get_hk_historical_k_data' that appear to handle different markets. The purpose is 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for different markets (US, HK, general) and data types, there's no indication of when this specific US-focused tool is appropriate versus 'get_historical_k_data' or other market-specific variants. No usage context 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?
No annotations are provided, so the description carries the full burden. It mentions the return format ('Markdown格式的基本信息表格' - Markdown format basic information table), which adds some behavioral context. However, it lacks critical details: whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what happens with invalid codes. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the purpose is stated first, followed by Args and Returns sections. Every sentence earns its place by clarifying parameters and output. It could be slightly more concise by integrating the example directly, but overall it's efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, 1 required), no annotations, and an output schema exists (implied by 'Returns'), the description is minimally adequate. It covers purpose, parameters, and output format, but lacks usage guidelines, behavioral details like error cases, and doesn't leverage sibling context. With output schema handling return values, the description meets basic needs but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description compensates well: it explains 'code' as '美股代码' (US stock code) with an example ('us.AAPL'), and 'fields' as '可选的字段列表' (optional field list). This adds meaningful semantics beyond the bare schema. However, it doesn't specify possible field values or formats, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取美股基本信息' (Get US stock basic information). It specifies the verb '获取' (get) and resource '美股基本信息' (US stock basic information), making it distinct from siblings like 'get_us_stock_realtime_data' or 'get_us_historical_k_data'. However, it doesn't explicitly differentiate from 'get_stock_basic_info' (which might be for other markets), 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_us_stock_realtime_data' for real-time data or 'get_stock_basic_info' for other markets. There's no context about prerequisites, such as needing a valid stock code, or exclusions. The minimal guidance is insufficient for an agent to make informed choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format ('Markdown格式' - Markdown format), which is useful. However, it lacks critical behavioral details: whether this is a read-only operation, potential rate limits, authentication needs, data freshness (e.g., delayed vs. real-time), error handling, or what happens with invalid codes. For a real-time data tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the core purpose is stated first, followed by Args and Returns sections. Every sentence earns its place by clarifying the parameter and output format. Minor improvements could include bolding key terms, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (real-time data fetching), no annotations, and an output schema (which handles return values), the description is minimally adequate. It covers the purpose, parameter meaning, and output format, but lacks behavioral context (e.g., rate limits, errors) and usage guidelines relative to siblings. With output schema existing, it doesn't need to detail return structure, but other gaps keep it from higher scores.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the single parameter 'code': it explains it's a US stock code with an example format ('us.AAPL' for Apple). Since schema description coverage is 0% (the schema only provides a generic 'Code' title with no details), this compensates well. However, it doesn't cover edge cases (e.g., invalid codes, formatting rules), preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取美股实时行情数据' (Get US stock real-time market data). It specifies the verb ('获取' - get) and resource ('美股实时行情数据' - US stock real-time market data), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_hk_stock_realtime_data' or 'get_historical_k_data', which would require 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_us_historical_k_data' for historical data, 'get_us_stock_basic_info' for static information, or 'get_us_market_indices' for broader market data. There's no context about prerequisites, timing, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('Markdown格式的杜邦分析数据表格或错误信息' - Markdown-formatted DuPont analysis data table or error message), which adds some value. However, it lacks critical behavioral details such as whether this is a read-only operation, potential rate limits, authentication needs, data freshness, or error handling specifics. For a data retrieval tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded. It starts with the core purpose, followed by a structured 'Args' and 'Returns' section with bullet points. Every sentence earns its place by defining parameters and output format without redundancy or fluff, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has an output schema), the description is partially complete. It covers parameter semantics well and mentions the return format, but lacks behavioral context (e.g., read-only status, error conditions). The output schema existence means the description doesn't need to detail return values, but overall gaps in usage guidelines and transparency keep it at a baseline adequacy level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter: 'code' as '港股代码 (如 'hk.00700')' (Hong Kong stock code, e.g., 'hk.00700'), 'year' as '4位年份 (如 '2023')' (4-digit year, e.g., '2023'), and 'quarter' as '季度 (1, 2, 3, 或 4)' (quarter: 1, 2, 3, or 4). This compensates fully for the schema's lack of descriptions, providing clear semantics and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取港股季度杜邦分析数据 (ROE分解)' translates to 'Get Hong Kong stock quarterly DuPont analysis data (ROE decomposition)'. It specifies the verb ('get'), resource ('Hong Kong stock DuPont analysis data'), and scope ('quarterly'), which distinguishes it from siblings like 'get_dupont_data' (likely general) or 'get_hk_stock_analysis' (broader). However, it doesn't explicitly differentiate from all siblings, such as 'get_hk_profit_data', which might overlap in financial 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or comparisons to sibling tools like 'get_dupont_data' (for non-HK stocks) or 'get_hk_stock_analysis' (for broader analysis). Usage is implied by the parameters but not explicitly stated, leaving the agent to infer context from the tool name and parameters 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?
No annotations are provided, so the description carries full burden. It mentions the return format (Markdown) but lacks critical behavioral details: it doesn't specify if this is a read-only operation, potential rate limits, authentication needs, data freshness, or error handling. The description adds minimal value beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a brief purpose statement followed by clear 'Args' and 'Returns' sections with essential details. Every sentence earns its place with no wasted words, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and sibling tools present, it lacks guidance on usage and behavioral context, leaving gaps for an agent to operate effectively in this server's ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'code' is a Hong Kong stock code and provides a concrete example ('hk.00700' for Tencent), clarifying format and semantics that the schema alone does not cover.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('港股实时行情数据' meaning 'Hong Kong stock real-time market data'), making the purpose specific. It distinguishes from siblings like 'get_hk_historical_k_data' (historical data) and 'get_hk_stock_basic_info' (basic info), but doesn't explicitly mention these distinctions in the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't compare to 'get_us_stock_realtime_data' for US stocks or 'get_hk_stock_analysis' for analytical data, leaving the agent to infer usage from tool names 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?
No annotations are provided, so the description carries full burden. It mentions the return format ('Markdown格式' - Markdown format) which is useful, but doesn't disclose important behavioral aspects: whether this is a real-time or cached list, what criteria define 'popularity', rate limits, authentication needs, or error conditions. For a tool with no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place: the first states what the tool does, the second explains the single parameter, and the third specifies the output format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, list retrieval), the description covers the basics: purpose, parameter meaning, and output format. However, with no annotations and many sibling tools, it lacks context about when to use it versus alternatives and behavioral details. The existence of an output schema reduces the need to fully describe returns, but more operational context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 1 parameter, the description compensates well by explaining the 'limit' parameter's purpose ('返回的股票数量限制' - limit on number of stocks returned) and default value (20). This adds meaningful context beyond what the bare schema provides, though it doesn't specify range constraints or special cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: '获取热门港股列表' (Get popular Hong Kong stock list). It specifies the verb ('获取' - get) and resource ('热门港股列表' - popular HK stock list), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_hs300_stocks' or 'get_popular_us_stocks' beyond the HK 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for different markets (US, HK, indices) and data types (real-time, historical, analysis), the description lacks any context about when this specific 'popular stocks' list is appropriate compared to other stock retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool fetches data and returns a markdown table or error message, but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or what happens when date parameters are omitted. The description provides basic functional information but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections: a purpose statement, parameter documentation, and return value description. Every sentence earns its place - the first sentence states the core functionality, and the Args/Returns sections provide essential usage information without redundancy. The formatting with clear section headers enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (implied by 'Has output schema: true'), the description appropriately focuses on functionality rather than return value details. It covers the core purpose and parameter semantics well, though it could benefit from more behavioral context given the lack of annotations. For a data-fetching tool with 2 optional parameters, this description provides adequate context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It clearly explains that start_date and end_date are optional parameters in 'YYYY-MM-DD' format for defining a date range, which the schema only indicates through titles and nullability. This compensates well for the schema's lack of descriptions, though it doesn't explain default behavior when parameters are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches benchmark deposit rates (活期, 定期) within a date range, providing specific verb ('fetches'), resource ('benchmark deposit rates'), and scope ('within a date range'). It distinguishes itself from sibling tools like get_loan_rate_data or get_shibor_data by focusing specifically on deposit rates rather than loan rates or interbank rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions date range parameters, it doesn't specify scenarios where this tool is appropriate versus other financial data tools in the sibling list, such as get_loan_rate_data for loan rates or get_shibor_data for interbank rates. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('Markdown table with growth capability data or an error message'), which adds some context, but fails to cover critical aspects like data sources, rate limits, authentication needs, error handling specifics, or whether the operation is read-only or has side effects. This leaves significant gaps for an agent to understand the tool's behavior fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by 'Args' and 'Returns' sections. Each sentence adds value, such as specifying data types and examples, without unnecessary fluff. However, it could be slightly more front-loaded by integrating the return format into the initial sentence for faster comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It excels in parameter semantics and purpose clarity but lacks usage guidelines and sufficient behavioral transparency (e.g., no info on data freshness or error conditions). The presence of an output schema reduces the need to detail return values, but overall gaps remain in guiding effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explicitly defines each parameter: 'code' as 'The stock code (e.g., 'sh.600000'),' 'year' as 'The 4-digit year (e.g., '2023'),' and 'quarter' as 'The quarter (1, 2, 3, or 4).' This includes examples and constraints, fully compensating for the schema's lack of documentation and ensuring clarity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches quarterly growth capability data (e.g., YOY growth rates) for a stock,' specifying the verb ('fetches'), resource ('growth capability data'), and scope ('quarterly,' 'for a stock'). However, it does not explicitly differentiate from sibling tools like 'get_hk_growth_data' or 'get_profit_data,' which may also fetch financial data, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as sibling tools like 'get_hk_growth_data' for Hong Kong stocks or 'get_profit_data' for other financial metrics. It lacks context on prerequisites, exclusions, or comparisons, offering only basic parameter usage without strategic 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches data and returns a markdown table or error, but lacks details on permissions, rate limits, data freshness, or error conditions. For a data-fetching tool with zero annotation coverage, this is insufficient to inform the agent about operational constraints or risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by Args and Returns sections. Every sentence adds value, such as clarifying date formats and year_type options. It could be slightly more concise by integrating the purpose with parameter details, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers parameters well and mentions the return format (markdown table or error), but lacks behavioral context like data sources, update frequency, or error handling. The output schema likely details the return structure, so the description doesn't need to explain return values, but it should address other operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains all three parameters: start_date and end_date as optional date ranges in 'YYYY-MM-DD' format, and year_type as optional with enums '0' for announcement date (default) and '1' for effective date. This fully compensates for the schema's lack of descriptions, providing clear semantics and usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches required reserve ratio data (存款准备金率) within a date range,' specifying both the verb ('fetches') and the resource ('required reserve ratio data'). It distinguishes itself from siblings by focusing on reserve ratio data rather than stock, financial statement, or rate data. However, it doesn't explicitly contrast with similar tools like get_deposit_rate_data or get_money_supply_data, keeping it from 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, such as needing specific permissions or data availability, nor does it suggest other tools for related tasks like get_deposit_rate_data or get_money_supply_data. The lack of usage context leaves 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?
No annotations are provided, so the description carries the full burden. It mentions the tool provides '数据驱动的分析报告' (data-driven analysis reports) and not investment advice, which hints at read-only behavior, but fails to disclose critical traits like whether it requires authentication, rate limits, data freshness, or error handling. For a tool with no annotations, this leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose, followed by Args and Returns sections. Every sentence adds value: the first sets scope, Args detail parameters, and Returns outline output. It could be slightly more concise by integrating the disclaimer into the purpose statement, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (Returns section describes the report content), the description doesn't need to detail return values. However, with no annotations and moderate complexity (analysis tool with parameters), it lacks completeness in behavioral aspects like permissions or limitations. The parameter semantics are covered, but overall context is adequate yet not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% schema description coverage. It explains that 'code' is a stock code like 'sh.600000' and 'analysis_type' has options ('fundamental', 'technical', 'comprehensive'), clarifying usage that the schema alone does not provide. With only 2 parameters, this compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool '提供基于数据的股票分析报告' (provides data-driven stock analysis reports) with a specific verb ('提供') and resource ('股票分析报告'), distinguishing it from siblings that focus on raw data (e.g., get_balance_data, get_historical_k_data). However, it doesn't explicitly differentiate from get_hk_stock_analysis, which appears to be a Hong Kong-specific variant, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying it provides '基于数据的股票分析报告，而非投资建议' (data-driven analysis reports, not investment advice), which suggests it's for informational analysis rather than decision-making. However, it lacks explicit guidance on when to use this tool versus alternatives like get_stock_basic_info for basic data or get_hk_stock_analysis for Hong Kong stocks, and 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return format ('Markdown table with cash flow data or an error message'), which adds some behavioral context. However, it lacks details on permissions, rate limits, data freshness, or error conditions, which are important for a data-fetching tool with no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and uses bullet-like formatting. It's appropriately sized with no redundant information, though the 'Args' and 'Returns' labels are slightly verbose compared to a more streamlined approach.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has an output schema), the description is fairly complete. It covers the purpose, parameters with examples, and return format. The output schema existence means the description doesn't need to detail return values, but it could benefit from more behavioral context (e.g., error handling, data sources).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose and provides examples (e.g., 'code: The stock code (e.g., 'sh.600000')', 'year: The 4-digit year (e.g., '2023')', 'quarter: The quarter (1, 2, 3, or 4)'), fully compensating for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches quarterly cash flow data for a stock' with a specific example ('CFO/Operating Revenue ratio'), which is a clear verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_hk_cash_flow_data' or 'get_balance_data', which appear to fetch similar financial data for different markets or types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for financial data (e.g., 'get_hk_cash_flow_data', 'get_balance_data', 'get_profit_data'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the return format (Markdown table or error) but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or what happens with invalid inputs beyond error messages. For a data retrieval tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose first, followed by parameter details and return format. Every sentence adds value, though the structure could be slightly improved by separating the purpose from the parameter explanations more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has output schema), the description is reasonably complete. It covers purpose, parameters, and return format. With an output schema present, it doesn't need to detail return values extensively, though more behavioral context would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter: 'code' as Hong Kong stock code with example 'hk.00700', 'year' as 4-digit year with example '2023', and 'quarter' as 1-4 with examples. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Hong Kong stock quarterly balance sheet/solvency data with specific examples (current ratio, debt ratio). It distinguishes from siblings by specifying '港股' (Hong Kong stocks) focus, though it doesn't explicitly differentiate from similar tools like 'get_balance_data' or 'get_hk_cash_flow_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_balance_data' (general balance data) or 'get_hk_cash_flow_data' (cash flow data for Hong Kong stocks). The description implies usage for Hong Kong stock balance sheet analysis but lacks explicit comparison or exclusion 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'Markdown格式的盈利能力数据表格或错误信息' (Markdown-formatted profitability data table or error message), which adds some context about output format and error handling. However, it lacks details on permissions, rate limits, data freshness, or whether this is a read-only operation (though 'get' implies reading). For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated first, followed by parameter details and return information. Every sentence adds value: the first defines the tool, and the subsequent lines explain inputs and outputs. It could be slightly more concise by integrating the parameter explanations more tightly, but it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is reasonably complete. It explains the purpose, parameters, and return format. Since an output schema exists, the description doesn't need to detail return values extensively. However, it could improve by adding more behavioral context (e.g., data sources, limitations) to compensate for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'code' is a '港股代码 (如 'hk.00700')' (Hong Kong stock code, e.g., 'hk.00700'), 'year' is a '4位年份 (如 '2023')' (4-digit year, e.g., '2023'), and 'quarter' is '季度 (1, 2, 3, 或 4)' (quarter: 1, 2, 3, or 4). This clarifies the semantics, formats, and constraints for all three parameters, fully 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取港股季度盈利能力数据 (如ROE、净利润率等)', which translates to 'Get Hong Kong stock quarterly profitability data (such as ROE, net profit margin, etc.)'. This specifies the verb ('get'), resource ('Hong Kong stock profitability data'), and scope ('quarterly'), making the purpose clear. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_profit_data' or 'get_hk_balance_data', which might handle different data types or markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_profit_data' (which might be for non-HK stocks) or 'get_hk_balance_data' (for balance sheet data), nor does it specify prerequisites or exclusions. Usage is implied only by the tool's name and description, with no explicit 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?
No annotations are provided, so the description carries full burden. It mentions the return format ('Markdown table with profitability data or an error message'), which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, rate limits, authentication requirements, data freshness, or what specific profitability metrics are included beyond the examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It begins with the core purpose, then clearly documents parameters with examples, and ends with return information. Every sentence 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with no schema descriptions and no annotations, the description does a good job explaining parameters and return format. However, for a data-fetching tool with many similar siblings, it should provide more context about when to use it versus alternatives and what specific data it returns. The existence of an output schema helps, but the description could better prepare the agent for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantics for all 3 parameters: 'code' (stock code with example), 'year' (4-digit year with example), and 'quarter' (quarter number with valid values). This adds significant value beyond the bare schema, which only provides titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetches quarterly profitability data (e.g., ROE, net profit margin) for a stock.' It specifies the verb ('fetches'), resource ('quarterly profitability data'), and provides examples of metrics. However, it doesn't explicitly differentiate from sibling tools like 'get_hk_profit_data' or 'get_balance_data', which likely fetch different types of financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools fetching different financial data types (balance, cash flow, growth, etc.), there's no indication of when profitability data is appropriate versus other metrics, nor any prerequisites or exclusions 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?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'fetches' data and returns a Markdown table or error, but lacks details on behavioral traits such as rate limits, authentication needs, data freshness, or error handling specifics. This is inadequate for a tool with no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the purpose, followed by clear parameter explanations and return details in a bullet-like format. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is mostly complete. It covers the purpose, parameters, and return format. However, it lacks behavioral context (e.g., error conditions, data sources) and usage guidelines relative to siblings, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'code' parameter format (e.g., 'sh.600000'), the 'year' parameter usage, and provides detailed options and defaults for 'year_type' (e.g., 'report' vs 'operate' with explanations). 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetches dividend information for a given stock code and year.' It specifies the verb ('fetches'), resource ('dividend information'), and scope ('stock code and year'). However, it does not explicitly differentiate from sibling tools like 'get_hk_dividend_data', which serves a similar purpose for Hong Kong stocks, leaving room for improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools (e.g., 'get_hk_dividend_data' for Hong Kong stocks) or contextual factors like data availability or prerequisites. Usage is implied by the parameters 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'fetches' data and returns a markdown table or error, but does not cover critical aspects like authentication needs, rate limits, data freshness, or error handling specifics. This is a significant gap for a data-fetching tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear purpose statement followed by structured sections for Args and Returns. Every sentence earns its place, providing essential information without waste, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is mostly complete. It covers the purpose, parameters, and return format. However, it lacks behavioral context like error conditions or usage guidelines, which would be needed for a perfect score, especially without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It clearly explains each parameter: 'code' as the stock code with an example, 'year' as the 4-digit year with an example, and 'quarter' as the quarter with valid values. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches quarterly DuPont analysis data (ROE decomposition) for a stock,' specifying the verb (fetches), resource (DuPont analysis data), and scope (quarterly, for a stock). However, it does not explicitly differentiate from sibling tools like 'get_hk_dupont_data' or other data-fetching tools, which would require 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_hk_dupont_data' for Hong Kong stocks or other financial data tools in the sibling list. It lacks explicit when/when-not instructions or named alternatives, offering only implied usage through parameter context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns dividend data in Markdown table format or error messages, which adds some behavioral context. However, it lacks details on permissions, rate limits, data freshness, or error handling specifics, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement followed by labeled sections for Args and Returns. Each sentence adds value without redundancy, and the information is front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple data retrieval with 2 parameters) and the presence of an output schema (which handles return values), the description is mostly complete. It covers the purpose, parameter semantics, and output format. However, it could improve by adding usage guidelines or more behavioral details, especially since annotations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'code' is a Hong Kong stock code with an example ('hk.00700') and 'year' is the year with an example ('2023'), clarifying the parameter formats and usage 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取港股分红信息' (Get Hong Kong stock dividend information), specifying both the action (get) and resource (Hong Kong stock dividend data). It distinguishes from siblings like 'get_dividend_data' by specifying the Hong Kong market focus, though it doesn't explicitly contrast with all 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While it implicitly targets Hong Kong stocks, it doesn't mention when to choose it over other dividend-related tools like 'get_dividend_data' or market-specific tools, nor does it specify 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('fetches'), implies a read-only operation, and specifies the return format ('Markdown table' or 'error message'), which is helpful. However, it lacks details on rate limits, authentication needs, error conditions beyond generic messages, or data freshness, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement followed by formatted sections for arguments and returns. Every sentence adds value without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 optional parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, parameters, and return format. However, it could improve by addressing usage context relative to siblings or providing more behavioral details like data sources or update frequency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that parameters are optional date ranges in 'YYYY-MM-DD' format, clarifying their purpose and format. Since there are only 2 parameters and the schema lacks descriptions, this compensation is effective, though it doesn't detail default behaviors when dates are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('fetches') and resource ('benchmark loan rates'), and it specifies the scope ('within a date range'). However, it doesn't explicitly differentiate from sibling tools like 'get_deposit_rate_data' or 'get_shibor_data', which appear to fetch similar financial data but for different 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts for application, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('Markdown table with operation capability data or an error message'), which is helpful, but does not cover other traits like rate limits, authentication needs, error conditions beyond generic messages, or data freshness. For a data-fetching tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured: a clear purpose statement followed by 'Args' and 'Returns' sections with bullet points. Each sentence earns its place by providing essential information without 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching financial data with 3 parameters), no annotations, and an output schema (implied by 'Returns' statement), the description is largely complete. It covers purpose, parameters, and return format. However, it lacks behavioral details like error handling specifics or data source context, which could enhance completeness for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explicitly documents all three parameters ('code', 'year', 'quarter') with examples and constraints (e.g., '4-digit year', quarter as 1-4), fully compensating for the schema's lack of details. This provides clear semantic context for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetches quarterly operation capability data (e.g., turnover ratios) for a stock.' It specifies the verb ('fetches'), resource ('quarterly operation capability data'), and scope ('for a stock'), but does not explicitly differentiate it from sibling tools like 'get_hk_operation_data' or 'get_balance_data' which might fetch similar financial data for different markets or aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools fetching financial data (e.g., 'get_balance_data', 'get_profit_data', 'get_hk_operation_data'), it lacks explicit context, prerequisites, or exclusions to help an agent choose appropriately. Usage is implied by the data type but not clearly distinguished.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the return format (markdown table with 1/0 indicators) and default date values, which adds useful context beyond just the function name. However, it doesn't mention important behavioral aspects like rate limits, authentication requirements, data freshness, or error conditions that would be important for an agent to know when invoking this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses efficient language. Every sentence earns its place by providing essential information. It could be slightly more concise by combining some information, but overall it's 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (though not shown in the prompt), the description doesn't need to fully explain return values, and it appropriately describes the output format. With 2 parameters and no annotations, the description provides good coverage of parameter semantics and basic behavioral context. For a data-fetching tool with date parameters, this is reasonably complete, though it could benefit from more behavioral context about limitations or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (schema only has titles 'Start Date' and 'End Date'), the description fully compensates by providing detailed parameter semantics. It specifies the date format ('YYYY-MM-DD'), indicates both parameters are optional, documents the default values (2015-01-01 for start_date, current date for end_date), and explains the null handling. This adds substantial meaning beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches trading dates information within a specified range', which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its many sibling tools (like get_latest_trading_date or get_historical_k_data), which also deal with date-related financial data. The purpose is 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools dealing with financial data (e.g., get_latest_trading_date, get_historical_k_data, get_stock_basic_info), there's no indication of when this specific trading dates tool is appropriate versus other date-related or market data tools. The description only explains what the tool does, not when to choose 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source ('Baostock') and return format ('Markdown formatted string'), but lacks critical behavioral details such as rate limits, authentication requirements, error handling specifics, or whether the operation is read-only or has side effects. For a tool with no annotations, this leaves significant gaps in understanding its 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured, with a clear purpose statement, usage hint, and detailed parameter documentation. It is front-loaded with the core functionality. Minor improvements could include briefer formatting, but overall it is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching financial data with three parameters), no annotations, and an output schema present, the description is fairly complete. It covers purpose, parameters, and return format. However, it lacks some contextual details like error scenarios or data freshness, which could enhance completeness for the agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the input schema provides no descriptive information about parameters. The description compensates fully by detailing each parameter's semantics in the Args section: 'code' specifies Baostock format with examples, and 'start_date'/'end_date' specify the required date format. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('fetches'), resource ('adjustment factor data'), and scope ('for a given stock code and date range'). It distinguishes from siblings by mentioning the specific data source ('Baostock's "涨跌幅复权算法" factors') and use case ('useful for calculating adjusted prices'), which is unique among the listed sibling tools that focus on different financial 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the tool is 'useful for calculating adjusted prices', which suggests when to use it. However, it does not explicitly state when to use this tool versus alternatives (e.g., other data-fetching tools in the list) or provide exclusions, leaving some ambiguity for the agent in 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that reports are not always required, hinting at potential empty results, but does not cover other critical aspects such as authentication needs, rate limits, error handling, or whether this is a read-only operation. The description is too sparse for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by a note on limitations, and then clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has an output schema), the description is reasonably complete. It covers the purpose, parameter semantics, and return format (Markdown table or error message). The output schema existence means the description doesn't need to detail return values, but it could improve by addressing behavioral aspects like error conditions or data freshness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'code' is a stock code with an example ('sh.600000'), and clarifies that start_date and end_date are for 'report publication/update' in 'YYYY-MM-DD' format. This compensates well for the schema's lack of descriptions, though it could provide more context on valid date ranges or code formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches performance forecast reports (业绩预告) for a stock within a date range,' specifying the verb (fetches), resource (performance forecast reports), and scope (stock, date range). It distinguishes from siblings by focusing on forecast reports rather than other financial data types like balance sheets or historical prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by noting 'Companies are not required to publish these except in specific cases,' which suggests this tool may return empty results. However, it lacks explicit guidance on when to use this tool versus alternatives like get_performance_express_report or other financial data tools, and does not mention 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?
With no annotations provided, the description carries the full burden. It discloses that returns are in 'Markdown table' format and mentions the optional nature of these reports, which adds useful context. However, it doesn't describe error handling beyond 'error message', rate limits, authentication needs, or data freshness—significant gaps 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a contextual note, and separate Args/Returns sections. It's appropriately sized, but the note about optional publishing could be more integrated; otherwise, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters), no annotations, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, parameter semantics, and output format. However, it lacks behavioral details like error conditions or data availability constraints, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains that 'code' is a stock code with an example ('sh.600000'), clarifies that dates are for 'report publication/update' (not trading dates), and specifies the date format ('YYYY-MM-DD'). This fully compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches performance express reports for a stock within a date range' with a specific verb ('fetches'), resource ('performance express reports'), and scope ('for a stock within a date range'). It distinguishes the resource type from siblings like 'get_forecast_report' or financial data tools, but doesn't explicitly differentiate usage context from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'Companies are not required to publish these except in specific cases' provides implied guidance about when data might be unavailable, but doesn't explicitly state when to use this tool versus alternatives like 'get_forecast_report' or other financial data tools. No clear usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool fetches data (implying read-only) and returns either a markdown table or error message, which covers basic behavior. However, it lacks details about rate limits, authentication requirements, data freshness, or what specific error conditions might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses exactly three sentences with zero wasted words. Each sentence earns its place by providing essential information without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 optional date parameters), no annotations, but with an output schema (implied by 'Returns' statement), the description is reasonably complete. It covers what data is fetched, parameter details, and return format. The main gap is lack of behavioral context like rate limits or error specifics, but the output schema reduces the need to fully describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents both parameters (start_date and end_date) with format details ('YYYY-MM-DD') and clarifies they're optional. Since schema description coverage is 0% (titles only provide 'Start Date'/'End Date'), the description adds significant value by specifying the exact date format and optional nature, though it doesn't explain default behavior when dates are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('fetches') and resource ('SHIBOR data'), and distinguishes it from siblings by specifying the exact financial data type (SHIBOR rates). It's not a tautology and provides meaningful differentiation from tools like get_loan_rate_data or get_deposit_rate_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions fetching SHIBOR data, it doesn't specify use cases, prerequisites, or contrast with similar tools like get_loan_rate_data that might provide different interest rate data. The agent receives 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?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior by specifying the scope ('A-shares and indices'), date handling, and return format. However, it lacks details on rate limits, error conditions, or data freshness, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear purpose statement followed by structured 'Args' and 'Returns' sections. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema (implied by 'Returns'), the description is mostly complete. It covers purpose, parameters, and return format well, but could improve by adding behavioral context like data sources or limitations, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains the 'date' parameter's optional nature, format ('YYYY-MM-DD'), default behavior (current date if None), and purpose, fully compensating for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('fetches a list') and resources ('all stocks (A-shares and indices) and their trading status'), and distinguishes it from siblings by focusing on comprehensive stock listing rather than specific data types like historical prices or financial reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. While it implies usage for date-specific stock listings, it doesn't mention when to choose this over tools like 'get_stock_basic_info' or 'get_hs300_stocks', nor does it specify 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?
With no annotations provided, the description carries full burden. It discloses the tool's read-only nature through 'fetches' and describes the return format (Markdown table or error message), but lacks details about data freshness, rate limits, authentication requirements, or error conditions beyond the generic 'error message' mention. The behavioral disclosure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by dedicated Args and Returns sections. Every sentence adds value: the first establishes context, the second explains parameter behavior, and the third defines output format. There's no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single optional parameter), no annotations, and the presence of an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It covers purpose, parameter usage, and return format, though additional context about data sources or limitations would enhance completeness 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter, but the description compensates by clearly explaining the 'date' parameter's purpose, format ('YYYY-MM-DD'), optional nature, and default behavior (uses latest if None). This adds significant semantic value beyond the bare schema, though it doesn't cover edge cases like invalid date formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('fetches') and resource ('constituent stocks of the CSI 300 Index'), distinguishing it from sibling tools like get_sz50_stocks and get_zz500_stocks which target different indices. It precisely defines the scope as retrieving index constituents rather than individual stock data 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing CSI 300 constituents, but provides no explicit guidance on when to use this tool versus alternatives like get_all_stock or get_stock_basic_info. It mentions the optional date parameter but doesn't explain scenarios where date specification is necessary versus using the default latest date.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's based on current real dates (not training data), returns a formatted string, and should be called first in analysis workflows. However, it doesn't mention potential limitations, error conditions, or whether the timeframe calculation involves any external data fetching or computation costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage guidance, parameters, returns) and uses efficient language. Every sentence adds value, though the parameter documentation could be slightly more concise. The formatting with clear headings enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter with enum values), no annotations, and the presence of an output schema (implied by the Returns section), the description is quite complete. It covers purpose, usage context, parameter semantics, and return format. The main gap is lack of behavioral details about potential limitations or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It fully documents the single parameter 'period' with all possible enum values ('recent', 'quarter', 'half_year', 'year'), their meanings, and the default value. This completely compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取适合市场分析的时间范围' (get suitable timeframe for market analysis) and specifies it's based on current real dates rather than training data. It distinguishes itself from siblings by focusing on timeframe calculation rather than data retrieval, though it doesn't explicitly contrast with specific alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: '在进行市场分析或大盘分析时首先调用' (should be called first when conducting market or overall market analysis). It establishes a prerequisite role but doesn't explicitly mention when NOT to use it or name specific alternative tools for different 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?
With no annotations provided, the description carries the full burden. It discloses key behaviors: it fetches data (read-only implied), handles optional parameters with defaults, and returns a markdown table or error. However, it lacks details on rate limits, authentication needs, data freshness, or error specifics, which are important for a tool with no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose in the first sentence. The Args and Returns sections are clear and efficient, with no redundant information. Every sentence adds value, making it appropriately concise for a tool with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 optional parameters) and no annotations, the description is mostly complete: it explains purpose, parameters, and output. However, it lacks behavioral details like error handling or data sources. The presence of an output schema reduces the need to detail return values, but more context on limitations would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema by explaining parameter purposes (e.g., 'stock code' with an example 'sh.600000'), optionality, and default behaviors ('If None, uses the latest available date'). This covers both parameters adequately, though it could specify format constraints more explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('fetches industry classification') and resources ('for a specific stock or all stocks'), distinguishing it from siblings like get_stock_basic_info or get_stock_analysis. It explicitly mentions the scope (single vs. all stocks) and the date parameter, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through parameter descriptions (e.g., 'If None, fetches for all stocks'), but it does not explicitly state when to use this tool versus alternatives like get_stock_basic_info or get_stock_analysis. No exclusions or prerequisites are mentioned, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (Markdown table or error message) and default behavior (uses latest date if none provided), which adds useful context. However, it lacks details on rate limits, authentication needs, or error conditions beyond the generic mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value without redundancy, and it's 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter) and the presence of an output schema, the description provides sufficient context for basic use. It covers purpose, parameter semantics, and return format, though it could benefit from more behavioral details like error handling or performance expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description fully documents the single parameter 'date', including its optional nature, format ('YYYY-MM-DD'), and default behavior (uses latest if None). This compensates well for the lack of schema documentation, though it doesn't explain potential constraints like valid date ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('fetches') and resource ('constituent stocks of the SZSE 50 Index'), distinguishing it from siblings like get_hs300_stocks and get_zz500_stocks which fetch different indices. It precisely defines the scope 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving SZSE 50 Index constituents, but does not explicitly state when to use this tool versus alternatives like get_all_stock or get_stock_basic_info. No exclusions or prerequisites are mentioned, leaving some context gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool fetches data (read-only behavior implied) and returns either a markdown table or error message, but lacks details on rate limits, authentication needs, data freshness, or error conditions. It adds basic context but misses deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by specific sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single optional parameter) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, parameter semantics, and return format. However, it lacks details on error handling or data source limitations, leaving minor gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema: it explains that the 'date' parameter is optional, uses 'YYYY-MM-DD' format, defaults to the latest available date if None, and clarifies the parameter's purpose. With 0% schema description coverage, this fully compensates for the single parameter, providing clear usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Fetches') and resource ('constituent stocks of the CSI 500 Index'), distinguishing it from sibling tools like get_hs300_stocks and get_sz50_stocks that fetch different indices. It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving CSI 500 Index constituents, but does not explicitly state when to use this tool versus alternatives like get_hs300_stocks or get_sz50_stocks. No guidance on prerequisites, exclusions, or specific scenarios is provided, leaving usage context inferred 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?
With no annotations provided, the description carries full burden. It discloses the return format (Markdown table or error message) and the default behavior when fields parameter is None/empty. However, it doesn't mention rate limits, authentication requirements, data freshness, or error conditions beyond the generic 'error message' reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value: the opening statement defines scope, parameter descriptions provide essential usage details, and the return statement clarifies output format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with output schema), the description provides good coverage of purpose, parameters, and return format. However, it lacks information about behavioral constraints (rate limits, auth) and doesn't fully explain the relationship with sibling tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantics for both parameters: code format (Baostock format with examples), fields parameter behavior (optional list, example values, default behavior when None/empty). This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches basic information for Chinese A-share stocks, specifying both the action ('fetches') and resource ('basic information for a given Chinese A-share stock'). It distinguishes from siblings like get_hk_stock_basic_info and get_us_stock_basic_info by specifying 'Chinese A-share' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the stock type specification (Chinese A-share) and parameter examples, but doesn't explicitly state when to use this tool versus alternatives like get_stock_analysis or get_stock_industry. No explicit when-not-to-use guidance or prerequisite 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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns a single date, handles non-trading days by returning the previous trading date, and specifies the output format. However, it lacks details on timezone handling, data freshness, or error conditions, which are relevant for a date-related tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core functionality in the first sentence, followed by a clear 'Returns' section. Every sentence adds essential value: the first explains the logic, the second specifies the format. There is zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, simple logic), no annotations, and the presence of an output schema (implied by 'Has output schema: true'), the description is nearly complete. It covers purpose, behavior, and output format. A minor gap is the lack of explicit mention of timezone or data source, but overall it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately focuses on behavior and output without redundant parameter info, earning a baseline 4 for effectively handling the zero-parameter case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('获取' meaning 'get/retrieve') and resource ('最近的交易日期' meaning 'latest trading date'), distinguishing it from siblings like 'get_trade_dates' which likely returns multiple dates. It precisely defines what 'latest' means in terms of current vs. previous trading days.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to get the most recent trading date, handling non-trading days), but does not explicitly mention when not to use it or name specific alternatives like 'get_trade_dates' for broader date queries. This gives good guidance but lacks explicit 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?
With no annotations provided, the description carries full burden and does well: it discloses output format (Markdown table), potential truncation for large results, error message returns, and data source specifics (Baostock format/options). It doesn't mention rate limits, authentication needs, or data freshness, but covers key behavioral aspects for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, Args, Returns) and no wasted sentences. The parameter explanations are detailed but necessary given 0% schema coverage. Slightly verbose due to enum listings, but each line earns its place by providing critical semantic information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with 0% schema coverage, no annotations, but with output schema present, the description provides complete context: clear purpose, detailed parameter semantics, output format disclosure, and behavioral notes (truncation, errors). It fully compensates for the lack of structured metadata, making the tool understandable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate - and it does excellently. Each parameter gets detailed semantics: code format examples, date formats, frequency/enum mappings with explanations, adjust_flag meanings with Chinese terms, and fields behavior with defaults. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('fetches historical K-line (OHLCV) data') and resource ('for a Chinese A-share stock'), distinguishing it from siblings like 'get_hk_historical_k_data' (Hong Kong stocks) and 'get_us_historical_k_data' (US stocks). It precisely identifies the data type and market 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests usage for Chinese A-share stocks (vs. HK/US siblings), but lacks explicit when-not-to-use guidance or named alternatives. It provides context about data source (Baostock) and format, which helps in tool selection, but doesn't explicitly compare to other data-fetching tools like 'get_stock_realtime_data'.
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:

[![stockreport-mcp MCP server](https://glama.ai/mcp/servers/jamesdingAI/stockreport-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jamesdingAI/stockreport-mcp)

Score Badge

Copy to your README.md:

[![stockreport-mcp MCP server](https://glama.ai/mcp/servers/jamesdingAI/stockreport-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jamesdingAI/stockreport-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jamesdingAI/stockreport-mcp'

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