Server Quality Checklist

Tool Scores

• block_tradeC
  2.9/5.0
  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 what data is retrieved but doesn't describe key behavioral traits such as whether this is a read-only operation (implied by '获取'), potential rate limits, authentication requirements, data freshness, or error handling. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and key data details. There's no wasted text or redundancy. However, it could be slightly more structured by explicitly separating purpose from data elements, but it remains efficient and clear.

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

  Completeness2/5

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

  Given the complexity of financial data retrieval, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., read-only nature, rate limits), output format, error conditions, and usage context relative to siblings. While the purpose is clear, the tool's operational context and limitations are underspecified for effective agent use.

  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 no parameter-specific information beyond what the input schema provides. The schema has 100% description coverage, clearly documenting all three parameters ('code', 'start_date', 'end_date') with examples and optionality. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate with additional semantic context.

  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 block trade data) with specific details like '成交价格、成交量、买卖双方营业部等详细信息' (transaction price, volume, buyer/seller departments, etc.). It uses a specific verb ('获取') and resource ('大宗交易数据'), making the purpose unambiguous. However, it doesn't explicitly distinguish this tool from potential siblings like 'stock_data' or 'margin_trade', which might also involve trading data but for different contexts.

  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 specific scenarios, prerequisites, or exclusions, nor does it reference sibling tools like 'stock_data' or 'margin_trade' that might overlap in financial data retrieval. Usage is implied by the tool's name and description but lacks 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.

• company_performanceC
  2.9/5.0
  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. While it indicates this is a data retrieval operation ('获取'), it doesn't disclose important behavioral traits: whether this requires authentication, rate limits, data freshness, error conditions, or response format. The description lists data types but doesn't explain how they're returned or structured. For a tool with 5 parameters and no annotations, this is a significant gap in behavioral transparency.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('获取上市公司综合表现数据') followed by a comprehensive list of included data types. While the list is lengthy, each data type mentioned is relevant and earns its place by clarifying the tool's scope. There's no redundant information or unnecessary elaboration.

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

  Completeness2/5

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

  Given the tool's complexity (5 parameters, 22 data_type options, no output schema, and no annotations), the description is insufficiently complete. It doesn't explain how the different data types are returned, what the response structure looks like, or how to interpret the results. For a financial data tool with multiple parameter combinations and no output schema, users need more guidance about what to expect from the tool's behavior and outputs.

  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 lists the types of data available (业绩预告, 业绩快报, 财务指标, etc.) which corresponds to the 'data_type' parameter's enum values. However, with 100% schema description coverage, the input schema already thoroughly documents all 5 parameters including detailed descriptions and enum values. The description adds minimal value beyond what's already in the structured schema, meeting the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '获取上市公司综合表现数据' (retrieve comprehensive performance data for listed companies). It specifies the verb ('获取' - retrieve) and resource ('上市公司综合表现数据' - listed company comprehensive performance data), and lists multiple data types included. However, it doesn't explicitly differentiate from sibling tools like 'company_performance_hk' or 'company_performance_us' which likely serve similar purposes for 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 'company_performance_hk' or 'company_performance_us' for different markets, nor does it explain when to use this versus other financial data tools like 'stock_data' or 'index_data'. There's no context about prerequisites, limitations, or appropriate use cases beyond the broad data retrieval statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• company_performance_hkC
  2.9/5.0
  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 indicates this is a data retrieval tool (implied read-only), it doesn't address important behavioral aspects like authentication requirements, rate limits, data freshness, error conditions, or response format. For a financial data tool with no 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 a single, efficient Chinese sentence that states the core purpose. It's appropriately sized for a data retrieval tool and front-loads the essential information. While it could potentially be more structured, there's no wasted verbiage or redundancy.

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

  Completeness2/5

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

  For a financial data tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what data format is returned, whether results are paginated, what happens when no data is found, or how to interpret the financial metrics. The combination of moderate complexity and lack of structured metadata means the description should provide more operational context.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description mentions financial statement types (income, balance, cashflow) which aligns with the 'data_type' parameter, but doesn't add meaningful semantic context beyond what's already in the schema descriptions. With 100% schema description coverage, the baseline is 3. The description doesn't explain parameter interactions (like how 'period' overrides date ranges) or provide examples of valid 'ind_name' values beyond the two examples given.

  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 comprehensive performance data for Hong Kong-listed companies, including financial statement data such as income statements, balance sheets, and cash flow statements). It specifies the verb ('获取' - get/retrieve) and resource (Hong Kong-listed company financial data), but doesn't explicitly differentiate from sibling tools like 'company_performance' and 'company_performance_us' beyond the 'hk' designation in the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/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 'company_performance' (likely for mainland China companies) or 'company_performance_us' (for US companies), nor does it specify use cases, prerequisites, or exclusions. The only contextual clue is the 'hk' in the tool name, but this isn't explained in the description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• company_performance_usC
  2.9/5.0
  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. While it mentions what data is returned, it doesn't describe important behavioral aspects: whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, error conditions, or response format. For a financial data tool with 5 parameters, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is a single, efficient Chinese sentence that states the core purpose and lists the four data types. There's no wasted verbiage or redundant information. However, it could be slightly more structured by separating the purpose from the data type enumeration for better readability.

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

  Completeness2/5

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

  Given the complexity (financial data tool with 5 parameters, no annotations, no output schema), the description is incomplete. It doesn't address key contextual elements: what the output looks like, data format, pagination if any, error handling, or performance characteristics. For a tool that returns potentially complex financial data, users need more context about what to expect from the response.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter interactions, default behaviors, or provide examples of valid combinations. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

  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 comprehensive performance data for US-listed companies) and specifies the data types included (income statement, balance sheet, cash flow statement, financial indicators). It distinguishes from sibling tools like 'company_performance' and 'company_performance_hk' by specifying US stocks. However, it doesn't explicitly mention the verb 'retrieve' or 'fetch' - it uses '获取' which is equivalent.

  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 'company_performance' (likely for non-US stocks) or 'company_performance_hk' (Hong Kong stocks), nor does it provide any context about prerequisites, limitations, or typical use cases. The user 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.

• csi_index_constituentsC
  2.9/5.0
  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 lists what data is retrieved but doesn't mention rate limits, authentication requirements, data freshness, pagination, error conditions, or whether this is a read-only operation. For a data retrieval tool with 3 parameters, 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 a single, dense sentence that efficiently lists all data types retrieved. While comprehensive, it could benefit from structural separation of the different data categories. However, every element serves a purpose and there's no wasted text.

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

  Completeness3/5

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

  For a data retrieval tool with 3 parameters and no output schema, the description provides good coverage of what data is returned but lacks information about return format, structure, or limitations. Without annotations or output schema, the agent has incomplete context about how to interpret results.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, providing good documentation for all 3 parameters. The description doesn't add parameter-specific information beyond what's in the schema, but with complete schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

  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 data for CSI indices including market performance, constituent weights, and valuation/financial metrics. It specifies the resource (CSI indices) and verb (获取/retrieve), but doesn't explicitly differentiate from sibling tools like 'index_data' which might have overlapping functionality.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/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. The description doesn't mention sibling tools like 'index_data' or specify use cases, prerequisites, or exclusions. The agent must infer usage from the description alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• finance_newsC
  2.9/5.0
  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 '通过真正的搜索API' (via a real search API) and '智能搜索' (intelligent search), which hints at external data retrieval but doesn't cover critical aspects like rate limits, authentication needs, response format, or error handling. For a tool that likely makes external API calls, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that conveys the core functionality without unnecessary details. It is appropriately sized and front-loaded with the main purpose, though it could be slightly more structured to separate purpose from usage hints.

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

  Completeness2/5

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

  Given the complexity of a news search tool with no annotations and no output schema, the description is incomplete. It lacks information on what the tool returns (e.g., article titles, dates, sources), how results are formatted, pagination, or error cases. This makes it inadequate for an agent to use the tool effectively without guesswork.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, with the 'query' parameter fully documented in the schema. The description adds minimal value beyond the schema by reiterating support for single or multiple keywords with examples like '药明康德' and '美联储 加息'. However, it doesn't provide additional semantics such as search logic nuances or result limitations, so it meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '获取主流财经媒体的新闻内容' (get financial news content from mainstream media) and '支持单个或多个关键词智能搜索' (supports single or multiple keyword intelligent search). It specifies the verb (获取/get) and resource (新闻内容/news content), though it doesn't explicitly distinguish from sibling tools like 'hot_news_7x24' which might have similar functions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/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 'hot_news_7x24' or 'macro_econ'. It mentions support for single or multiple keywords but doesn't specify use cases, prerequisites, or exclusions. The lack of sibling tool differentiation leaves the agent without clear selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fund_dataC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral information. It states what data can be retrieved but doesn't disclose important behavioral traits like rate limits, authentication requirements, data freshness, potential performance implications (especially for 'all' data type), or what happens when large historical datasets are requested. The description is purely functional without 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.

  Conciseness4/5

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

  The description is appropriately concise - a single sentence that efficiently communicates the scope of available data. It's front-loaded with the core purpose and follows with specific examples. While brief, every word serves a purpose in defining the tool's capabilities.

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

  Completeness2/5

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

  For a tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address how results are structured, what format data is returned in, whether pagination is needed for large result sets, or any error conditions. The description covers 'what' data is available but not 'how' to effectively retrieve it or interpret results.

  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?

  With 100% schema description coverage, the baseline is 3. The description doesn't add meaningful parameter semantics beyond what's already documented in the schema. It mentions the data types available but doesn't provide additional context about parameter interactions, default behaviors, or practical usage patterns that would help an agent understand how to effectively use the parameters together.

  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 comprehensive public fund data) and lists specific data types including fund lists, fund managers, net values, dividends, and holdings. It distinguishes from siblings by focusing on fund data specifically, though it doesn't explicitly contrast with fund_manager_by_name which appears to be a related but different tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/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 the sibling tool 'fund_manager_by_name' or explain when to choose one over the other. There's no context about appropriate use cases, prerequisites, or limitations beyond what's implied by the parameter descriptions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hot_news_7x24C
  2.9/5.0
  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 source ('Tushare新闻接口') and implies real-time/latest news ('最新的'), but lacks critical details: it doesn't specify authentication needs, rate limits, error handling, or what '7x24' operationally means. The schema description mentions content deduplication, but this isn't highlighted in the main description. For a news-fetching 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 a single, efficient sentence that front-loads the core purpose. It wastes no words but could be slightly more structured (e.g., separating source from categories). However, it appropriately conveys the essential information without redundancy.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., news format, fields, timestamps) or behavioral aspects like pagination, rate limits, or error conditions. For a news-fetching tool that likely returns structured data, this leaves significant gaps for an AI agent to understand how to interpret results.

  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 no parameter information beyond what the schema provides. The input schema has 100% description coverage for the single parameter 'limit', detailing its purpose, default, range, and deduplication behavior. With high schema coverage and only one parameter, the baseline score of 3 is appropriate - the description doesn't compensate but doesn't need to given the schema's completeness.

  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: '从Tushare新闻接口获取最新的财经、政治、科技、体育、娱乐、军事、社会、国际等新闻' (fetch latest news from Tushare news API across multiple categories). It specifies the verb ('获取' - fetch), resource ('新闻' - news), and source ('Tushare新闻接口'). However, it doesn't explicitly differentiate from sibling tools like 'finance_news' - both appear to fetch news, though 'hot_news_7x24' emphasizes 'latest' and '7x24' (24/7) while 'finance_news' might be finance-specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/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 'finance_news' or explain scenarios where this tool is preferred (e.g., for broader news categories vs. finance-only). There's also no information about prerequisites, timing considerations, or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• index_dataC
  2.9/5.0
  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 retrieves data but doesn't describe what type of data (e.g., historical prices, volumes, returns), how it's returned (e.g., format, structure), any rate limits, authentication needs, or error handling. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that directly states the purpose with examples. It's appropriately sized and front-loaded, with no wasted words. However, it could be slightly more structured by explicitly mentioning the data type or use case.

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

  Completeness2/5

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

  Given the complexity of a data retrieval tool with 3 required parameters, no annotations, and no output schema, the description is incomplete. It lacks details on what data is returned, behavioral traits, and differentiation from siblings. While the schema covers parameters well, the overall context for effective tool use is insufficient.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, with each parameter ('code', 'start_date', 'end_date') well-documented in the schema. The description adds no additional parameter semantics beyond implying the tool handles stock indices. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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 data for specified stock indices) with examples like '上证指数、深证成指等' (Shanghai Composite Index, Shenzhen Component Index, etc.). It specifies the verb '获取' (get) and resource '股票指数的数据' (stock index data), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'stock_data' or 'csi_index_constituents', which might also involve stock-related 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 mentions examples of indices but doesn't specify use cases, prerequisites, or exclusions. Given sibling tools like 'stock_data' (likely for individual stocks) and 'csi_index_constituents' (likely for index components), the lack of differentiation leaves the agent without clear usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• macro_econC
  2.9/5.0
  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. The description only states what data can be retrieved but doesn't disclose important behavioral traits: it doesn't mention whether this is a read-only operation, what format the data returns in, whether there are rate limits, authentication requirements, or any potential side effects. For a data retrieval tool with zero annotation coverage, this represents a significant gap in behavioral transparency.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that immediately states the purpose and provides a comprehensive list of available indicators. There's no wasted space or redundant information. While it could potentially benefit from more structural elements (like separating purpose from indicator list), it's appropriately concise for its scope.

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

  Completeness2/5

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

  Given that there are no annotations and no output schema, the description is incomplete for a data retrieval tool with 3 required parameters. While the purpose is clear, the description doesn't address critical contextual elements: what format the data returns in, whether there are pagination considerations, error conditions, or any behavioral constraints. For a tool that presumably returns complex economic data, this represents a significant completeness gap.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, with all three parameters (indicator, start_date, end_date) having clear descriptions in the schema. The description text lists indicator examples that align with the schema's enum-like description, but adds no additional semantic context beyond what's already documented in the schema. This meets the baseline expectation when schema coverage is complete.

  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 macroeconomic data) and provides a comprehensive list of specific indicators (Shibor利率, LPR利率, GDP, CPI, etc.). It uses a specific verb ('获取' - get/retrieve) and identifies the resource type (macroeconomic data). However, it doesn't explicitly distinguish this tool from potential sibling tools that might also retrieve economic data, though none of the listed siblings appear to overlap directly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/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, limitations, or scenarios where other tools might be more appropriate. While the sibling tools list doesn't show obvious alternatives for macroeconomic data, the description offers no explicit usage context or comparisons.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• margin_tradeC
  2.9/5.0
  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 describes what data can be retrieved but lacks critical behavioral details: it doesn't specify if this is a read-only operation, mention rate limits, authentication needs, or describe the response format. For a data retrieval tool with multiple parameters and no annotations, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is concise and front-loaded, stating the core purpose in the first clause and listing data types efficiently. It uses a single sentence with no wasted words, making it easy to parse. However, it could be slightly more structured by separating purpose from data type examples.

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

  Completeness2/5

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

  Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It covers what data can be retrieved but lacks information on behavioral traits, output format, and usage context. For a financial data tool with multiple data types and parameters, more guidance is needed to ensure proper agent invocation.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema by listing data types (e.g., 标的股票, 交易汇总) that correspond to the data_type parameter, but it doesn't provide additional syntax, format, or usage context. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 margin trading related data). It specifies the verb (获取/get) and resource (融资融券相关数据/margin trading related data), making the action explicit. However, it doesn't distinguish this tool from its siblings (e.g., stock_data, money_flow) in terms of domain specificity beyond listing 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 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 lists supported data types but doesn't explain scenarios for choosing this tool over siblings like stock_data or money_flow, nor does it mention prerequisites or exclusions. Usage is implied through the data types 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.

• stock_data_minutesC
  2.9/5.0
  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. The description mentions the tool '支持' (supports) specific frequencies and requires start/end datetime, but doesn't disclose critical behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, data freshness, error handling, or what the output looks like. 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 concise and front-loaded, stating the core purpose in the first phrase. The single sentence efficiently covers markets, frequencies, and time range requirement. However, it could be slightly more structured by separating market support from frequency options for clarity.

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

  Completeness2/5

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

  Given the complexity (5 required parameters, no annotations, no output schema), the description is incomplete. It adequately states what the tool does but lacks crucial context: no output format information, no behavioral details (rate limits, errors), no differentiation from siblings, and minimal parameter guidance beyond schema repetition. For a data retrieval tool with multiple parameters, this leaves the agent under-informed.

  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 mentions the supported frequencies (1MIN/5MIN/15MIN/30MIN/60MIN) and that time range is required, but the schema already has 100% coverage with detailed descriptions for all 5 parameters. The description doesn't provide additional context like parameter interactions, constraints, or examples beyond what's in the schema.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '获取分钟K线数据' (get minute K-line data) for A股/加密 (A-shares/crypto). It specifies the resource (K-line data) and scope (minute-level, specific markets). However, it doesn't explicitly distinguish this from sibling tools like 'stock_data' or 'index_data', which might also provide stock-related data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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 mentions supported markets (A股/加密) and frequency options, but doesn't explain when this tool is appropriate compared to other stock data tools in the sibling list, such as 'stock_data' (which might provide different granularity) or 'index_data' (which might provide index-level data).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fund_manager_by_nameB
  3.1/5.0
  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 this is a query operation ('查询'), implying it's likely read-only, but doesn't confirm this or describe other traits like error handling, rate limits, authentication needs, or response format. For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond the basic purpose.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose and lists key return details. Every part earns its place: it specifies the action, target, and information returned without redundancy or unnecessary elaboration. It's appropriately sized for a simple query tool.

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

  Completeness3/5

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

  Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and return types but lacks behavioral context, usage guidelines, and output details. Without annotations or an output schema, the agent must infer behavior from the description alone, which is incomplete for safe and effective use. It meets the bare minimum but has clear gaps.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description doesn't add meaning beyond what the input schema provides. Schema description coverage is 100%, with clear documentation for both parameters ('name' and 'ann_date'), including examples and formats. The description mentions querying by name but doesn't elaborate on parameter usage, constraints, or interactions. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter semantics adequately.

  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: '根据基金经理姓名查询基金经理详细信息' (query fund manager details based on name). It specifies the verb ('查询' - query) and resource ('基金经理详细信息' - fund manager details), and lists the types of information returned (managed fund list, personal background, work experience). However, it doesn't explicitly differentiate from sibling tools like 'fund_data' or 'stock_data', which might also involve fund-related queries.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/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, exclusions, or comparisons to sibling tools (e.g., 'fund_data' or others that might overlap with fund-related queries). Usage is implied only by the description's focus on fund manager details by name, but no explicit context or alternatives are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dragon_tiger_instB
  3.2/5.0
  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 ('返回表格包含' - returns a table containing) but lacks details on pagination, rate limits, authentication needs, error handling, or data freshness. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond basic input-output.

  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 front-loaded, stating the purpose and key parameters in a single sentence. Every element (purpose, required/optional parameters, return content) earns its place without redundancy. However, the lack of structural formatting (e.g., bullet points) and slightly dense phrasing in Chinese might reduce immediate clarity for non-native 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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameters but lacks details on output structure (beyond mentioning table content), error cases, or usage scenarios. Without annotations or output schema, more context on behavioral aspects would improve completeness for effective agent use.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for both parameters in the input schema. The description adds minimal value beyond the schema by reiterating that 'trade_date' is required and 'ts_code' is optional, but doesn't provide additional context like example usage patterns or implications of omitting the optional parameter. Baseline score of 3 is appropriate as the schema does the heavy lifting.

  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 '龙虎榜机构成交明细（top_inst）' (dragon-tiger list institutional transaction details), specifying it returns a table with buy/sell/net amounts and listing reasons. It uses specific verbs ('返回表格包含' - returns a table containing) and identifies the resource, but doesn't explicitly differentiate from sibling tools like 'block_trade' or 'money_flow' which might have overlapping financial data domains.

  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 required parameters ('必填：交易日期' - required: trade date) and optional ones ('可选：股票TS代码' - optional: stock TS code), which provides basic context for when to provide inputs. However, it doesn't offer explicit guidance on when to use this tool versus alternatives like 'stock_data' or 'money_flow', nor does it mention any exclusions or prerequisites beyond parameter requirements.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• current_timestampB
  3.3/5.0
  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 a timestamp in a specific time zone with datetime components, but lacks details on output format, error handling, rate limits, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond the basic purpose.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does (get timestamp) and key context (time zone, included components), making it highly concise and well-structured for quick understanding.

  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 (1 optional parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and time zone context but lacks details on output format, error cases, or usage scenarios, which could help an agent invoke it correctly in varied contexts. It meets minimum viability but has clear gaps.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with the 'format' parameter fully documented in the schema (including optional values like datetime, date, time, timestamp, readable). The description does not add any parameter semantics beyond what the schema provides, such as default behavior or examples, so it meets the baseline of 3 for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: '获取当前东八区（中国时区）的时间戳，包括年月日时分秒信息' (Get the current timestamp in the East 8th time zone (China time zone), including year, month, day, hour, minute, and second information). It specifies the verb ('获取' - get), resource ('时间戳' - timestamp), and scope (East 8th time zone with full datetime details), distinguishing it from siblings that handle financial data like stock_data or fund_data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or related tools, leaving the agent to infer usage based on the purpose alone. For example, it does not clarify if this is for system time retrieval versus other time-related operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• money_flowB
  3.3/5.0
  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 types of data retrieved but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied by '获取' but not explicit), any rate limits, authentication requirements, or how the data is returned (e.g., format, pagination). For a tool with 6 parameters and no annotations, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that front-loads the core purpose and lists key data points without unnecessary details. It could be slightly more structured by separating use cases, but it avoids redundancy and wastes no words, making it appropriately concise for the tool's complexity.

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

  Completeness2/5

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

  Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits (e.g., read-only status, error handling), output format, and practical usage guidelines. Without annotations or an output schema, the description should provide more context to help an agent invoke the tool correctly, but it falls short, leaving gaps in understanding how the tool behaves and what it returns.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter interactions, default behaviors (e.g., automatic judgment based on ts_code), or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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

  Purpose5/5

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

  The description clearly states the action ('获取' meaning 'get' or 'retrieve') and specifies the exact resource: '资金流向数据' (money flow data) for stocks, markets, and sectors. It distinguishes itself from siblings by focusing on money flow metrics like net inflow amounts and percentages across different order sizes (main force, ultra-large, large, medium, small), which is not covered by other tools like stock_data or index_data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by listing the data types (stocks, markets, sectors) and metrics, but does not explicitly state when to use this tool versus alternatives. For example, it doesn't compare to stock_data (which might provide general stock info) or specify scenarios where money flow data is preferred over other financial metrics. This leaves some ambiguity in tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• convertible_bondA
  3.5/5.0
  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. While it describes the two query modes, it doesn't mention important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what format the returned data takes. For a financial data tool with no 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.

  Conciseness5/5

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

  The description is efficiently structured in two sentences that clearly explain the two query modes. Every element serves a purpose: the first sentence states the overall function, and the second explains the two specific usage patterns. There's no wasted language or redundancy.

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

  Completeness3/5

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

  Given the tool's moderate complexity (4 parameters, two distinct query modes) and the absence of both annotations and output schema, the description provides adequate but incomplete coverage. It explains what the tool does and the two usage patterns, but doesn't address behavioral aspects, return formats, or error handling that would be important for proper tool invocation.

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

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds some context by explaining that 'ts_code' is used with 'info' type and date parameters are for 'issue' type queries, but this mostly reinforces what's already clear from the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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 convertible bond non-market data) with two specific query methods. It distinguishes between 'issue' type for time-range queries of issuance data and 'info' type for code-based detailed information queries. However, it doesn't explicitly differentiate from sibling tools like 'stock_data' or 'fund_data' which might handle similar financial instruments.

  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 each query type: use 'issue' type with date ranges for issuance data, and use 'info' type with codes for detailed information. It implicitly distinguishes between the two modes but doesn't explicitly state when NOT to use this tool versus alternatives like 'stock_data' for market data or other financial data tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• stock_dataA
  3.7/5.0
  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 describes what data is retrieved (historical market data) and supports technical indicators, but does not mention rate limits, authentication needs, data freshness, error handling, or response format. For a data retrieval tool with no annotation coverage, 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('获取指定股票/加密资产的历史行情数据') and then lists supported asset types and data sources. Every part earns its place by clarifying scope and sources without redundancy or fluff.

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

  Completeness3/5

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

  Given the tool's complexity (5 parameters, no output schema, no annotations), the description is moderately complete. It covers the purpose and asset scope well, but lacks details on behavioral aspects like rate limits or response structure, and does not fully compensate for the absence of annotations and output schema. It's adequate but has clear gaps for a data retrieval tool.

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

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value by specifying the asset types and data sources, which helps contextualize the 'market_type' and 'code' parameters, but does not provide additional syntax or format details beyond what the schema provides. With high schema coverage, the baseline is 3, but the description's contextual info justifies a 4.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('获取' meaning 'retrieve' or 'get') and resources ('历史行情数据' meaning 'historical market data'), and distinguishes it from siblings by specifying the asset types supported (A股, 美股, 港股, etc.) and data source for cryptocurrencies (CoinGecko). This is more specific than just 'stock data' and differentiates from tools like 'stock_data_minutes' or 'index_data'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by listing supported asset types and data sources, but does not explicitly state when to use this tool versus alternatives like 'stock_data_minutes' (which likely provides minute-level data) or 'index_data' (for index data). It provides context on what assets are covered but lacks explicit guidance on tool selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.