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

No annotations exist, so the description carries full burden. It notes data starts from 2016 but does not disclose read-only nature, rate limits, pagination, or other behavioral traits. For a query tool, this lack of transparency is a gap.

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

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

The description is well-structured with separate sections for purpose, parameters, and fields. It is reasonably concise given the amount of information, though the end_date parameter has a typo ('开始日期' instead of '结束日期').

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

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

Given no output schema, the Fields list implicitly indicates return values, but the description does not explicitly explain the output structure or any sorting/ordering. For a data retrieval tool, this lacks completeness compared to similar tools with richer descriptions.

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

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

The input schema provides no descriptions (0% coverage), but the description adds a detailed table explaining each parameter's purpose, format, and constraints (e.g., ts_code single stock, date format YYYYMMDD). The fields parameter is linked to the Fields list, providing clear selection guidance.

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

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

The description clearly states it retrieves fundamental data for a specific stock in a date range. However, it does not explicitly differentiate from sibling tools like stock_basic or daily, leaving some ambiguity about when to choose this tool.

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

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

The description mentions the constraint of querying only one stock per call, but does not provide guidance on when not to use this tool or suggest alternatives. Usage context is implied rather than explicit.

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

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

No annotations are provided, so the description must convey behavioral traits. It includes a constraint that only one stock can be queried per request (ts_code: '每次只能查询一支股票'). However, it lacks details on idempotency, rate limits, authorization, or what happens when data is missing. Partial disclosure but incomplete.

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

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

The description is extremely verbose, replicating the full parameter table and an extensive list of over 100 fields. The essential purpose is stated in the first two lines, but the bulk is redundant with the input schema and not front-loaded for quick scanning. This hinders efficient agent comprehension.

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

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

No output schema exists, so the description must explain return values. It provides a field list indicating what data can be retrieved, but does not describe the output structure (e.g., format, ordering, pagination) or error handling. For a data retrieval tool, this is adequate but not thorough.

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

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

The input schema has 0% description coverage, but the tool description contains a detailed parameter table with explicit descriptions in Chinese for each parameter (e.g., format for dates, period conventions). Additionally, a comprehensive list of available fields with Chinese labels is provided, adding significant meaning beyond the schema.

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

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

The description clearly states in Chinese and English that this tool retrieves balance sheet data for listed companies. It distinguishes itself from sibling tools like 'income' and 'cashflow' by specifying it covers the balance sheet, one of the three major financial statements.

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

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

The description implies usage for balance sheet queries but does not explicitly state when to use this tool over alternatives (e.g., income statement or cash flow). No guidance on when not to use or which conditions are appropriate is provided.

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

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

No annotations are provided, so the description carries full burden. It does not disclose authentication requirements, rate limits, data freshness, or any side effects. The description only lists parameters and fields, omitting behavioral traits essential for an agent to safely invoke the tool.

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

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

While the purpose is front-loaded, the description contains an excessively long field list (over 100 lines) that could be referenced externally. The parameter table is helpful but repetitively structured. More conciseness would improve readability without losing necessary detail.

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

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

For a data retrieval tool with 10 parameters and many fields, the description covers parameter formats and field names comprehensively. However, it lacks details on required parameters (ts_code is required per description but schema marks all optional), and does not explain the meaning of report_type or comp_type values, leaving minor gaps.

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

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

Schema description coverage is 0%, but the description compensates with a detailed table explaining each parameter and its expected format (e.g., 'ts_code: 股票代码，每次只能查询一支股票', 'ann_date: 公告日期（YYYYMMDD格式）'). This adds significant meaning beyond the schema titles, making the parameters easily interpretable.

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

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

The description clearly states the tool retrieves cash flow statement data for listed companies (上市公司现金流量表). The verb '获取' and resource '现金流量表数据' are specific. Sibling tools like 'balancesheet' and 'income' handle other financial statements, so this tool is well-distinguished.

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

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 'balancesheet' or 'income'. It does not mention prerequisites, typical use cases, or exclusions. The agent must infer the tool's purpose from its 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.

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 describes the tool as retrieving data (read operation) but does not explicitly state it is read-only, idempotent, or safe. No mention of rate limits, error behavior, or side effects. 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.

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

The description is well-structured with sections (Name, Description, Args, Fields). It is reasonably concise for the information provided, though the table could be slightly more compact. No wasted sentences.

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

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

Given the lack of output schema, the description helpfully lists the fields. It covers all arguments and their usage. However, it lacks examples, error handling details, or explanation of the output format (e.g., JSON structure). Adequate for simple data retrieval but could be more complete.

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

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

The description provides a detailed table for each parameter (m, start_m, end_m, fields) with format and usage, plus lists all possible field values. This adds significant meaning beyond the schema, which lacks descriptions. Schema coverage is 0%, so the description compensates fully.

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

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

The description clearly specifies that the tool retrieves CPI (Consumer Price Index) data, including national, urban, and rural datasets. This distinguishes it from sibling tools like cn_gdp or cn_pmi, which focus on other economic indicators.

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

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

The description explains how to use the parameters (m, start_m, end_m, fields) but does not explicitly state when to use this tool versus alternatives. It does not provide exclusions or guidance on choosing this tool over siblings, leaving the context implicit.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention whether the tool is read-only, if it requires authentication, or any side effects. The name and description imply it is a query, but this is not explicit.

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

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

The description is well-structured with clear sections (Name, Description, Args, Fields). It is concise yet informative, though the main description is only one sentence and could be expanded slightly to improve completeness.

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

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

The description adequately covers parameter usage but lacks details on output format (e.g., whether results are a list or single object) and behavior when no parameters are provided (e.g., returns all data). No output schema exists, so the description should fill this gap.

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

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

The description includes a detailed Args table explaining each parameter: 'q' format (e.g., 2019Q1) and support for multiple quarters, 'start_q' and 'end_q' for range queries, and 'fields' as a list of field names. It also specifies valid field names in a separate Fields section, adding significant value beyond the schema (which has 0% description coverage).

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

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

The description clearly states '获取国民经济之GDP数据' (Get GDP data of national economy), specifying the verb 'get' and the resource 'GDP data'. This distinguishes it from sibling tools that cover other economic indicators like CPI, PMI, etc.

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

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. No mention of prerequisites, typical use cases, or scenarios where other tools would be more appropriate.

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

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

No annotations are provided, so the description carries full behavioral disclosure burden. It states '获取' (get), implying a read operation, but does not disclose any additional traits such as data freshness, rate limits, or error conditions. For a simple data retrieval tool, this is adequate but not thorough.

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

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

The description is well-structured with a name, purpose statement, parameter table, and fields list. It is concise with no superfluous information, and the most important details (purpose and parameters) are front-loaded.

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

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

Given the tool's simplicity (no output schema required, no nested objects), the description is complete. It provides the return fields, parameter options, and clearly explains the data source (monthly money supply). No critical information is missing.

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

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

Schema description coverage is 0%, but the description compensates fully with a detailed parameter table listing all four parameters (m, start_m, end_m, fields) with clear descriptions and format requirements (YYYYMM). Additionally, the Fields list provides all selectable return fields, adding significant value beyond the bare schema.

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

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

The description clearly states it retrieves monthly money supply data (货币供应量之月度数据), with a specific verb ('获取') and resource ('货币供应量'). It distinguishes from sibling tools like cn_cpi or cn_gdp which cover different economic indicators.

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

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

The description does not explicitly state when to use this tool versus alternatives or any prerequisites. However, the context of sibling tools implies it is for money supply data, and the parameter table provides basic usage instructions. No explicit when-not-to-use guidance is given.

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

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

No annotations provided, and the description does not disclose behavioral traits such as data source, update frequency, rate limits, or default behavior when no parameters are given. Only the parameter table and field list are present.

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

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

The description is well-structured with sections for name, description, args, and fields. It front-loads the purpose. However, the field list is lengthy; it could be referenced as an appendix, but it remains necessary and organized.

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

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

Given the complexity (many fields) and absence of output schema and annotations, the description provides a comprehensive list of queryable fields and parameter explanations. Missing output format details, but the field list effectively conveys the data available.

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

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

Schema description coverage is 0%, but the description includes a detailed parameter table and an extensive field list with Chinese descriptions, providing meaning beyond the schema. The field list clearly explains each PMI sub-index, which is essential for correct parameter usage.

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

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

Description clearly states '获取采购经理人指数(PMI)数据' (Retrieve PMI data), specifying a clear verb and resource. It differentiates from sibling tools (e.g., cn_cpi, cn_gdp) which cover other economic indicators.

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

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 vs alternatives (e.g., other economic data tools). The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the field list.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, whether authentication is needed, rate limits, or any side effects. The minimal description '获取...数据' implies a safe read, but this is not explicit.

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

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

The description is well-structured with a name, description, args table, and fields list. It is front-loaded with purpose. The fields list is lengthy but necessary. No unnecessary sentences.

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

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

Given that there is no output schema, the description partially covers what data is returned via the fields list. However, it lacks details on response format, pagination, error handling, and default behavior when parameters are omitted.

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

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

The input schema has 0% description coverage, but the tool description provides a detailed table explaining each parameter's format and purpose. It also lists the available field values. This adds significant meaning beyond the schema's bare titles.

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

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

The description explicitly states the tool retrieves PPI producer price index data ('获取PPI工业生产者出厂价格指数数据'). The name and description are clear. However, it does not differentiate from sibling tools like cn_cpi or cn_gdp, but the specificity of PPI makes confusion unlikely.

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

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 compared to alternatives. The description does not mention prerequisites, exclusions, or when to prefer other tools. The parameter descriptions are present but usage context is missing.

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

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

No annotations provided, and the description lacks behavioral traits such as rate limits, permissions, or data freshness. It only mentions the unadjusted nature and parameter constraints like mutual exclusivity of trade_date with start_date/end_date.

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

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

Well-structured with tables and bullet points, but includes a redundant 'Name:' line. The description is clear and not overly verbose, though could be slightly more concise.

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

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

Given the lack of output schema, the description provides the available fields and explains them. Parameters are fully documented. However, it omits details on pagination, error handling, default behavior when no parameters are given, and historical data range.

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

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

With 0% schema description coverage, the description thoroughly documents all 5 parameters: ts_code (supports multiple stocks), trade_date (format and mutual exclusivity), start_date/end_date (must be used together), and fields (select from listed fields). It also lists available output fields with meanings.

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

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

The description clearly states the tool retrieves A-share daily market data without adjustment using specific verb '获取' and resource '日线行情数据'. It distinguishes from sibling tools like balance sheet or 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.

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 vs alternatives. The description implies usage for daily price data but does not provide exclusion criteria or comparison to other tools.

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

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

No annotations are provided, and the description lacks disclosure of behavioral traits such as required permissions, rate limits, or data freshness. The read-only nature is implied but not stated.

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

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

The description is front-loaded with a clear purpose but is lengthy due to a large field list and parameter table. While organized, it could be more concise for efficient use by an AI agent.

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

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

The description covers parameters and output fields adequately but lacks examples or explanations of parameter interactions (e.g., period vs date range). No output schema is provided, so return values are inferred from the field list.

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

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

The description includes a detailed table with parameter names, types, required status, and descriptions, compensating for the 0% schema description coverage. The extensive field list further clarifies the output options.

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

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

The description clearly states in Chinese that the tool retrieves income statement data for listed companies, distinguishing it from sibling tools like balancesheet and cashflow, which cover other financial statements.

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

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

The description implies usage for income statements but provides no explicit guidance on when to use this tool versus alternatives like balancesheet or cashflow, nor any conditions for 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.

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

No annotations are provided, and the description does not disclose behavior beyond the basic retrieval. It lacks details on authentication, rate limits, default behavior when parameters are omitted, or error handling.

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

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

The description is concise, uses a clear table for parameters, and lists fields in bullet points. No redundant content, and the structure is easy to parse.

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

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

The description adequately covers the 4 optional parameters and lists available fields, but lacks explanation of default return behavior when no parameters are specified. No output schema, but field list helps. It is fairly complete for a simple retrieval tool.

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

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

With 0% schema description coverage, the description compensates well by explaining parameter formats (YYYYMM), usage constraints (start_m/end_m paired), and field selection from a predefined list. This adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool retrieves monthly social financing data. The name 'sf_month' and description '获取月度社会融资数据' directly convey the purpose, and it is distinct from sibling tools like cn_cpi or cn_gdp.

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

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

The description provides parameter usage details (e.g., multiple months, start_m/end_m pairing) but does not offer guidance on when to use this tool over siblings. 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.

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

With no annotations, the description must fully disclose behavior. It lists parameters and fields but does not explain default behavior when no dates are given, update frequency, data sources, or error handling. This is minimal transparency.

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

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

The description is well-structured with sections for Name, Description, Args, and Fields. It is reasonably concise, though some repetition of 'LPR贷款基础利率' could be trimmed.

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

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

The Fields section implies return values (date, 1y, 5y), but it lacks details on default date range, rate precision, or data availability. For a simple lookup tool, it is adequate but not fully complete.

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

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

Despite 0% schema coverage, the description includes a table explaining each parameter: start_date and end_date must be used together, fields selects from the listed options. This adds meaningful context beyond the schema.

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

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

The description clearly states that the tool retrieves LPR (Loan Prime Rate) rates. It explains what LPR is, distinguishing it from sibling tools like cn_cpi or cn_gdp, but does not explicitly clarify that it returns historical time series.

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

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 other financial indicators. It lacks conditions, prerequisites, or situational recommendations.

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

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

No annotations provided; description lacks behavioral details such as read-only nature, data freshness, rate limits, or side effects. The tool is implicitly a query, but not stated.

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

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

Well-structured with separate Args and Fields tables, but somewhat lengthy. Could be more concise without losing essential info.

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

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

Comprehensive for a simple query tool: explains all parameters, includes return field descriptions. No output schema but fields table compensates. Complete context for basic stock info retrieval.

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

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

Schema coverage is 0% but the description includes a detailed table explaining each parameter's meaning, default, and possible values. The Fields table adds meaning to return values, compensates for lack of schema descriptions.

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

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

Description clearly states it retrieves basic stock info (name, code, etc.), with a specific verb '获取' and resource '基础信息'. It distinguishes from financial statement tools like balancesheet but doesn't explicitly differentiate from sibling bak_basic.

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

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

No guidance on when to use this tool versus alternatives like bak_basic or other stock info tools. No explicit when-not-to-use or prerequisite conditions.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, any authentication requirements, rate limits, or side effects beyond stating it 'gets' data.

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

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

The description is well-structured with sections (Name, Description, Args, Fields) and uses Markdown. It is somewhat lengthy but each part adds value. Could be slightly more concise.

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

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

Given no output schema and no annotations, the description covers parameter details and return fields adequately. However, it lacks explanation of behavior when multiple parameters are combined, and does not specify the output format or edge cases.

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

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

Schema description coverage is 0%, but the tool description provides detailed parameter descriptions in Chinese, including constraints (e.g., '每次只能查询一家公司') and enum values for exchange. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool retrieves basic company information ('获取上市公司基础信息'). The name 'stock_company' aligns with this purpose. However, it does not differentiate from sibling tool 'stock_basic', which may 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.

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

The description mentions that only one company can be queried at a time and allows selecting fields, but provides no guidance on when to use this tool versus alternatives (e.g., stock_basic) 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.