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

由于没有任何 annotations，描述承担了行为透明度的全部责任。它披露了返回“完整的7块REPORT JSON”这一输出行为，但未说明操作是否只读、数据来源、延迟或失败风险。反诈分析和报告性质暗示非破坏性，但未明确声明。

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?

整个描述只有一句话，动作、对象和输出契约都前置呈现，没有冗余。列举7个报告模块虽有细节但都是有效信息，结构紧凑。

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?

输入参数由 schema 完整覆盖，输出又有 output schema 说明返回结构，因此描述无需再解释返回值细节。对这类单一报告类工具，描述已经足够完整，但还缺少一句关于何时优先于其他诊断工具的引导。

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 为100%，因此参数语义基线为3。描述仅重复了“指定股票”，没有对 symbol 或 concept 参数增加额外语义，例如 concept 如何影响报告内容。

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?

描述明确说明了动作“执行反诈深度分析”和作用对象“指定股票”，并具体列出返回的7块REPORT JSON结构。这使它明显区别于其他股票分析类兄弟工具，用途非常清晰。

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?

描述隐含了使用场景：当用户需要对某只股票进行反诈深度分析时使用。但没有明确说明与兄弟工具（如 composite_stock_diagnostic、market_anomaly_scan）的选择边界，也没有给出何时不应使用该工具。

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 carries the behavioral burden; it discloses that every call recomputes from latest market/macro data and that results are 'daily fresh', implying results can change between calls. Output details are not described, but an output schema exists and this appears to be a side-effect-free computation.

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?

Two compact sentences front-load the core purpose via a colon and then add the key real-time behavior. The nested methodology list is dense but each element is informative, so the description remains efficient.

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 parameterless tool with an output schema, the description provides essential context: target market (China), asset classes, the four-layer framework, and real-time freshness. It does not explicitly delimit when to prefer sibling tools, but that is a minor gap given the clear niche.

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 tool has zero parameters, so the schema carries no parameter semantics to clarify. The 0-parameter baseline is 4, and the description appropriately focuses on the computation methodology instead.

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 states a specific verb ('动态计算') and resource ('中国周期调整资产配置...股票/债券/商品/现金配比'), so the tool's function is clear. It does not explicitly name or contrast the sibling fund_asset_allocation tool, relying instead on '中国市场' and asset-class wording for differentiation.

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 tool's usage is implied: call it to get a fresh, real-time China market cycle-adjusted allocation. However, there is no explicit when-to-use vs when-not-to-use guidance and no mention of alternatives among the many sibling 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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals an analytical perspective (volume contraction as a crash precursor), which is meaningful context, but it does not disclose data sources, update frequency, or whether it returns a risk score or raw signals. The output schema partially compensates, but operational behavior remains under-specified.

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?

Two short, information-dense sentences; the core monitoring purpose is front-loaded and the heuristic adds value without padding. Every word earns its place.

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 single-optional-parameter tool with an output schema, the description gives a clear scope and an analytical framework. It is slightly incomplete in explaining what form the monitored output takes, but given the simple parameter surface and existing output schema, it is adequately 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?

Schema description coverage is 100%, and the region parameter is already documented with its allowed values (china/japan/korea/all). The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool monitors asset bubble risk across Asia-Pacific, naming specific indicators like real estate transaction volume, housing prices, and equity valuation divergence. It is a specific verb+resource combination, though it does not explicitly distinguish itself from closely related market-monitoring siblings.

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 intended use case is implied: use this tool when assessing whether Asia-Pacific asset bubbles are forming or deflating. The heuristic 'volume falls before price' provides domain context, but there is no explicit guidance on when to prefer this tool over alternatives such as market_overview or sector_valuation.

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 present, so the description must carry the behavioral disclosure burden. It only says 'simple backtest' and does not explain what the tool returns, whether it is simulation-only, or how it handles data or strategy settings. This is a significant gap for a tool with no output schema.

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

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

The description is one front-loaded sentence with no filler: it names the action, the data basis, and the supported strategies compactly. It is concise without being under-specified in structure.

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?

With no output schema and no annotations, the agent lacks information about return values and invocation behavior. The tool is forgiving because all parameters are optional, but the missing output semantics and lack of differentiation from `backtest_strategy` leave too much to guess.

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 100%, and every parameter has a default and description, so the baseline applies. The description's mention of SMA/RSI/MACD merely echoes the `strategy` parameter and adds no extra constraints, syntax, or relational guidance 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 states a specific action ('简单策略回测') on historical price data and technical indicators, and explicitly names SMA/RSI/MACD. The title adds 'cryptocurrency', which distinguishes it from the sibling `backtest_strategy`, though the description body itself does not name the asset class.

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 for when to use this tool versus alternatives such as `backtest_strategy` or `trading_suggest`. The only scoping signal is the title, and an agent cannot infer when this should be preferred over the generic backtest sibling.

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?

无任何注解，描述需承担完全的行为披露责任。描述仅说明回测基于历史价格与技术指标，但未披露该操作是只读模拟、是否依赖特定数据源、是否有计算开销或结果形式。对于回测工具，未说明不会产生实际交易或需要额外权限。

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?

描述为单个简洁句子，核心动作和策略列表均前置，没有冗余内容。但缺少任何结构化信息（如使用条件、返回值），不过就其呈现的内容而言，已经做到简洁高效。

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?

工具拥有4个参数和6种策略，复杂度中等，且无输出schema。描述未说明回测结果的形态（如收益率、信号、图表），也未说明与crypto回测的边界，agent无法充分判断调用后的返回内容或限制。

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描述覆盖率达到100%，所有参数（symbol、days、market、strategy）在schema中已有清晰说明。描述中列出的策略类型与schema中strategy参数的枚举完全重复，未增加额外语义，因此维持基线3。

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?

描述明确说明了工具功能：基于历史价格与技术指标进行策略回测，并列出六种具体策略（SMA/RSI/MACD/BOLL/MA_CROSS/KDJ）。这足以让agent理解工具用途，但未明确区分于兄弟工具backtest_crypto_strategy，因为描述未指明本工具仅适用于股票市场，尽管schema中market参数暗示了这一点。

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?

描述完全没有提供使用场景或与替代方案的对比。没有说明何时应使用此工具而非backtest_crypto_strategy或其他技术指标类工具（如stock_tech_indicators），缺少when/when-not指导。

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 carry the burden of behavioral disclosure. It only says a report is fetched; it does not mention whether this is a read-only operation, what the report contains, whether the data is real-time or delayed, or whether there are any access constraints. The behavior of 'recommended use' is also left unexplained.

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 statement is brief and front-loads the core function with the verb and resource early in the sentence. The closing '推荐使用' is vague filler that does not add actionable information, but the overall length is appropriate and free of redundancy.

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?

With no output schema and many crypto-related sibling tools, the description is insufficiently complete. It does not explain what kind of analysis the report contains, how it differs from other diagnostics, or why an agent should select this tool. The low complexity and single parameter reduce the burden somewhat, but the lack of differentiation and return-value context leaves a notable 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?

Schema description coverage is 100% for the single symbol parameter, which already documents the format and default value. The tool description adds no additional parameter meaning or usage nuance, but since the schema fully covers the parameter, the baseline score of 3 is appropriate.

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

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

The description clearly states the verb '获取' and the resource '币安对加密货币的AI分析报告', which identifies a specific data product. It is distinguishable from sibling crypto data tools like crypto_prices or crypto_funding_rate because it focuses on an AI-generated analysis report, though it does not explicitly contrast itself with them.

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 phrase '推荐使用' vaguely suggests the tool is recommended, but it gives no concrete guidance on when to choose this tool over alternatives such as crypto_composite_diagnostic or crypto_sentiment_metrics. No exclusions, prerequisites, or selection criteria are provided, leaving the agent to infer usage context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does convey the core behavior — a one-time bulk fetch writing to local cache to avoid repeated network calls — which appropriately signals a stateful write operation. However, it does not disclose cache refresh semantics, idempotency, operation duration for large history pulls, or how an agent can verify or clear the populated cache afterward.

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?

Two sentences with no wasted words. The primary purpose is front-loaded in the first sentence, and the companion-tool relationship is given in the second. Every sentence earns its place.

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 zero-parameter prefetch tool with an existing output schema, this description is nearly complete: it names the data scope, the caching behavior, and the companion tool. The only gap is guidance on post-call verification (e.g., using cycle_cache_status or cache_status to confirm the cache was populated) and any note about the expected time cost of a full-history pull.

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 tool has zero parameters and an empty input schema, so the baseline of 4 applies — there is nothing for the description to document about arguments. The description appropriately focuses on what data is collected (bond yield curve, QVIX full history) instead of inventing parameter details.

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 states a specific action (一次性拉取/prefetch to cache), a specific resource (债券收益率曲线 and QVIX全量历史数据), and a destination (本地缓存). It also distinguishes itself from query siblings like bond_yields and option_ivix by clearly framing this as a collection/caching operation rather than a query.

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 gives clear usage context: call this to avoid repeated network requests when data will be queried multiple times. It names the companion tool cycle_collect, but does not explicitly exclude alternatives such as bond_yields, option_ivix, or cycle_cache_status, nor does it state when NOT to use this tool.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It discloses a key behavioral trait: the tool returns the full historical series in one response and leaves truncation to the frontend. It also clarifies the data contents (tenors and spreads). Minor unknowns like units and update frequency remain, but the core behavior is clear.

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?

Two tight sentences: the first defines scope and content, the second describes return behavior. No wasted words, and the most important information is front-loaded.

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

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

For a simple read-only query tool with two optional parameters and an output schema, the description covers the essential selection and invocation context. It names the data, tenors, spread, and full-history behavior. It doesn't mention units or data source, but given the output schema exists and there are no required parameters, this is largely sufficient.

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 100%, so the schema already documents both parameters fully. The description's 'front-end truncates as needed' comment loosely relates to the limit parameter but adds little beyond the schema. Baseline 3 is appropriate.

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 uses a specific verb and resource: it retrieves China and US treasury yield curve data, explicitly naming the tenors (2/5/10/30 year) and term spreads. This clearly distinguishes it from general macro or bond tools in the sibling list, even without naming an alternative.

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 the tool is for retrieving historical China/US treasury yield curve data, but it does not explicitly state when to prefer it over related siblings like macro_interest_rate or bond_collect. There is no mention of alternatives or exclusions.

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

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 only that it clears cache keys, but does not disclose potential side effects, irreversibility, impact on other tools, or what happens after clearing. 'Clear all' is a destructive operation that should be flagged more explicitly.

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 a single, front-loaded sentence with no filler. It efficiently communicates both the main action and the special case of clearing all caches.

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 simple one-parameter tool, the description is functionally sufficient for invocation. However, because there are no annotations and no output schema, the absence of any mention of side effects, destructive scope, or return behavior leaves the description slightly incomplete for an agent deciding whether and how to use it.

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 100%, and the input schema already explains that 'key' is the cache key and leaving it empty clears all cache. The description essentially restates this semantic, adding little beyond the schema, so baseline 3 is appropriate.

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 a specific action ('清理指定的缓存键，或清理所有缓存') with a clear resource and scope. It distinguishes this from the many data-retrieval siblings and from the similar cache_status tool by focusing on the clearing action.

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 intended use is straightforwardly implied: call when a cache key needs clearing or all cache needs clearing. However, it does not explicitly mention alternatives or when not to use it, such as checking cache_status first or whether clearing all caches is recommended.

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 carries the behavioral burden. It explicitly frames the operation as '查看' (view), implying a read-only, non-destructive behavior, and discloses what the agent can expect: the current cache keys and their count. It does not mention performance costs, but for a zero-parameter status tool this is not a major omission.

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 a single, efficient sentence that states the action, the resource, and the intended use with no redundant wording. It is appropriately sized for a zero-parameter status inspection tool.

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 simple zero-parameter tool, the description is complete: it states what the tool returns (keys and count), frames the operation as read-only, and gives the intended purpose. No output schema exists, but the description sufficiently covers the return expectations.

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 tool has zero parameters, so the schema already fully covers parameter semantics. The description has nothing to add, and the baseline of 4 applies.

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 uses a specific verb ('查看') and a specific resource ('当前缓存的键和数量'), clearly stating what the tool does. It does not explicitly contrast itself with the similar sibling 'cycle_cache_status', though the general 'cache' wording and the sibling's more specific name help distinguish them.

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 phrase '用于调试和监控' provides implied usage context: use this tool when debugging or monitoring cache state. However, it gives no explicit guidance about when to choose this over related siblings like 'cache_clear' or 'cycle_cache_status', and no exclusions or alternatives are mentioned.

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

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

There are no annotations, so the description carries the full burden. It reveals the count and categories of indices but does not disclose behavior such as whether data is returned as a series, whether an invalid name returns an error, pagination effects of limit, or any rate limits/access considerations.

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 a single compact sentence that front-loads the source and scope, then gives useful examples. It is concise and easy to scan, with no filler words.

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?

Although the tool is simple and has an output schema, the description lacks enough context for correct tool selection and parameter use. It does not mention the sibling caixin_list, clarify how limit affects results, or state whether name is an exact identifier or a fuzzy label. An agent could call it with defaults, but not confidently vary parameters.

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%, so the description must compensate. It indirectly suggests possible values for the name parameter by listing index categories, which is useful. However, it does not explicitly explain the limit parameter, how defaults interact, or that name must match one of the 19 specified indices.

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 identifies a specific resource (Caixin index data) and provides a concrete scope (19 indices) with examples such as digital economy, new economy, commodities, and PMI. It is clear that this tool retrieves Caixin index data, though it does not explicitly use a verb like 'get' or 'fetch'.

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

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

No guidance is given about when to use this tool versus alternatives like caixin_list or other index/data tools. The description implies use for Caixin index data but provides no exclusions, prerequisites, or selection criteria among the many sibling 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?

With no annotations provided, the description carries the burden of behavioral disclosure. '列出' clearly implies a read-only listing operation, and the count '19个' sets an expectation of a fixed, finite result set. However, it does not disclose whether the output contains codes, names, or other identifiers, nor whether a live data fetch is involved.

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 a single short sentence with no filler. It front-loads the core action and includes the useful count of available indices, making it appropriately 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?

For a zero-parameter list tool with an output schema present, the description is nearly complete: it states what is returned and the expected scope. The only meaningful gap is the lack of guidance about its relationship to the sibling 'caixin_indices'.

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 zero parameters, and schema description coverage is 100%, so the baseline for no parameters is 4. The description adds no parameter details, but none are needed.

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

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

The description clearly states a specific verb ('列出' / list) and resource ('所有可查的财新指数'), with an explicit count of 19. It is easy to understand what the tool does, but it does not explicitly distinguish itself from the similarly named sibling 'caixin_indices', so it falls just short of a 5.

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

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, and it does not mention the closely related sibling 'caixin_indices'. An agent must infer that this tool is the initial listing step before querying specific indices.

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 provided, the description carries the full burden of behavioral disclosure. It reveals that the tool can add or update, but does not explain how the upsert decision is made, whether an existing event is overwritten, what happens when fields are omitted, or whether the operation has side effects. This is a significant transparency gap for a mutation tool.

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

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

The description is compact and front-loaded: the first sentence states the core operation, and the second gives usage context. It avoids redundancy and fluff, though the brevity sacrifices detail that other dimensions require.

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 write/upsert tool with 8 undocumented optional parameters, no output schema, and no annotations, this description is far too thin. It fails to specify the update identity key, required fields, date format, or value conventions, so an agent cannot reliably invoke it correctly.

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% and the description adds no parameter-level meaning. The eight property names give hints, but the description says nothing about date format, which fields identify an existing event, the meaning of rating/sentiment, or allowed values. Since coverage is low, the description was expected to compensate and does not.

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 states a clear verb-resource pair: '新增或更新一条日历事件' (add or update a calendar event), and '每月日历维护入口' identifies it as the maintenance/write entry point. This distinguishes it from the many calendar read/query siblings like calendar_range, calendar_month, and calendar_event_detail.

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?

'每月日历维护入口' gives explicit context that this tool is the intended entry for calendar maintenance tasks, implying it should be used when adding or updating events. It does not explicitly name read-only alternatives or state when not to use it, so it stops short of a 5.

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

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

The description signals a read-only behavior with '返回' and discloses the return scope (complete event info with domains and targets). However, with no annotations provided, it does not cover what happens for invalid or missing ids, the default id of 0, or any other behavioral edge cases.

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

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

One compact sentence that front-loads the core operation and includes the most useful return details. Every part earns its place with no redundant filler.

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

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

For a simple one-parameter read tool, the description covers the main operation and return contents. But it lacks guidance on obtaining a valid event_id and does not address the surprising fact that no parameters are required, which could lead an agent to call it without meaningful input.

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%, so the description must compensate. It only says 'by id', which maps to event_id but adds little beyond the parameter name. It does not explain where the id comes from, the meaning of the default 0, or that the parameter is effectively required.

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 a specific verb and resource: return a single calendar event's complete information by id, including domains and targets. It is unambiguous about what the tool does, though it does not explicitly distinguish itself from sibling calendar tools.

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 given about when to use this tool versus alternatives like calendar_range, calendar_month, or calendar_upcoming. The phrase 'by id' implies the agent should already have an event_id, but there is no explicit context, prerequisite, or exclusion info.

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 present, so the description carries the full burden. It does disclose the calculation window, output fields, and the empty-targets fallback ('无 targets 时返回提示'). However, it does not explain the semantics of the color thresholds, the behavior when as_of is empty or invalid, or error handling for a nonexistent event_id. Useful but not complete behavioral disclosure.

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

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

A single dense sentence that front-loads the calculation, then covers coloring, output structure, and the no-targets edge case. Every clause contributes information; nothing is filler. Minor deduction for density — the parentheticals and run-on structure make it slightly harder to parse quickly — but it is far from verbose.

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?

With two optional parameters, no annotations, and no output schema, the description is the only documentation. It adequately covers the computation, the two return groups, and the fallback. Gaps remain: as_of semantics, color threshold definitions, and how to obtain a valid event_id (e.g., via calendar_event_detail or calendar_range are never referenced). For a calculation tool with this complexity, it is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It gives event_id meaning by anchoring the 30-trading-day window ('event-30交易日 → 今天'), and it explains what timeline/targets contain. But as_of is never mentioned at all — an agent cannot tell whether it is a valuation date, an output override, or the 'today' reference point. Compensation is partial, leaving a key parameter semantically dangling.

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 states a specific computation (cumulative gain over event-30 trading days → today), a coloring scheme (blue/green/orange/red for front-run degree), and the return shape (timeline, targets). This is clearly distinct from calendar_event_detail or calendar_range, though it never names those siblings explicitly. The verb '计算' plus resource '事件关联标的' makes the core purpose unambiguous.

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 when-to-use, when-not-to-use, or alternative routing is provided. Among roughly 200 siblings including 8 calendar_* tools, an agent gets zero guidance on when to pick calendar_frontrun over calendar_event_detail, calendar_range, or calendar_upcoming. The intended use case (assessing how much an event has been front-run) is only implied by the title, not stated as a usage rule.

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 provided, the description must carry the behavioral disclosure burden. It does state the core behavior—returning events for a given month—but it does not explain the meaning of default 0 values for year and month, or describe the returned event structure. This is a simple read operation, so the lack of side-effect warnings is acceptable, but default semantics remain unclear.

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 a single compact sentence that states both the function and the intended use case with no wasted words. It is front-loaded with the core action and easily scannable.

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 simple two-parameter read tool, the description covers the main purpose, but it leaves the default year=0/month=0 behavior unexplained and gives no hint about the event object shape. Given the absence of an output schema and annotations, slightly more context about defaults and return content would make it 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?

Schema description coverage is 0%, and the description only refers to '某年某月' without explaining the year and month parameters or their default values. The parameter names are self-explanatory, but the description adds no meaningful detail about valid ranges, what 0 means, or parameter formatting.

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 a specific action and resource: '返回某年某月的事件' (returns events for a given year and month) and adds the intended use case '用于月历渲染' (for calendar rendering). This distinguishes it from range-based or detail-oriented calendar siblings, though it does not explicitly name alternatives.

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

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

The phrase '用于月历渲染' gives an implied usage context, but there is no explicit guidance about when to choose this tool over calendar_range, calendar_upcoming, or calendar_event_detail. It does not state when-not-to-use or mention sibling alternatives.

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 accurately implies a read-only query, but it does not disclose output format, date format, behavior with empty defaults, or pagination. The week/month view note adds some context but not deep behavioral detail.

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

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

The description is a single, compact sentence that front-loads the core operation and the interval semantics, followed by the use case. Every word earns its place; there is no redundancy or fluff.

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?

While the tool is simple (two optional string parameters, no output schema), the description leaves essential invocation details unspecified: the expected date format, how start/end defaults behave, and whether the range is inclusive. Given the large sibling family, a bit more context about when to choose this over calendar_month or calendar_upcoming would improve completeness.

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 must compensate. It does add meaning by explicitly framing the query as '[start, end] 区间内的事件', indicating that start and end define the interval boundaries. However, it does not specify the expected string format (e.g., YYYY-MM-DD), inclusivity, or default behavior, leaving a gap.

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 uses a specific verb ('查询' / query), names the resource ('事件' / events), and defines the exact scope as the [start, end] interval. The added note '周/月视图用' (for week/month view) clearly distinguishes this from other calendar tools like calendar_upcoming or calendar_month.

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 gives a clear use context (week/month view) but does not explicitly name alternative tools or state when not to use it. It falls short of a 5 because it leaves the boundary with sibling calendar tools 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the key side effect (writing to reports.db), that it invokes an external script, and that it returns collection statistics. It does not disclose idempotency (whether repeated manual runs create duplicate events), runtime duration, or failure behavior, which are material concerns for a collect/refresh 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?

Three short sentences, each earning its place: the action and script, the data source and destination database, then the return value plus the scheduling note. The information is front-loaded with the triggering action first and contains no filler.

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 zero-parameter tool this is mostly complete: script, source, destination, return value, and automation status are all covered. The main gap is the vague return value ('采集统计') with no output schema to elaborate, and no statement about whether re-invocation is safe or duplicates results.

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 tool has zero parameters and an empty input schema, so the baseline of 4 applies. The description appropriately spends no space on parameter detail and instead focuses on the operation and its return value.

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 states a specific verb-resource pair: it manually triggers the script scripts/calendar_collect.py, pulls events from public calendars (解禁/新股/业绩预告), and writes them into reports.db. This differentiates it from the calendar query siblings (calendar_upcoming, calendar_range, calendar_month, calendar_event_detail) which are read tools, though it does not explicitly distinguish itself from the similarly named calendar_seed.

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 gives clear context — this is a manual trigger of an automated collection job — and notes that a scheduled task also runs it daily, which implies an agent may not need to call it for routine freshness. However, there is no explicit when-to-use versus alternatives or any exclusions, so the agent must infer that the calendar query tools are for reading the collected data.

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 carries the burden of behavioral disclosure. It does disclose the key safety property that the import is idempotent and repeatable, which is valuable. However, it does not state whether existing calendar data is overwritten, merged, or preserved, nor what side effects or return signals the call produces.

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?

A single front-loaded sentence states the action, the data source, the scope, and the safety property. Every phrase is relevant and there is no filler.

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 zero-parameter seed-import tool, the description gives the essential facts: what data is imported (PART 02, 10-week catalyst events) and that repeats are safe. It leaves out explicit return behavior and prerequisites, but the low complexity makes this acceptable.

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?

There are zero parameters and the schema is empty, so there is no parameter meaning for the description to add. The baseline of 4 applies, and the description correctly avoids inventing parameters.

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 names a specific action ('导入') and a specific resource ('《连板预测与大事日历》PART 02 结构化的10周催化事件'), and the title adds 'seed' to indicate bulk initialization. It is clear what the tool does, though it does not explicitly contrast itself with sibling calendar tools such as calendar_add.

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 its usage context: a repeatable seed import for the calendar dataset. The idempotency note is useful guidance, but there is no explicit when-to-use or when-not-to-use instruction and no mention of alternative calendar 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?

With no annotations provided, the description carries the full behavioral burden. It clearly indicates a read-like operation via '返回' and discloses that returned events include `days_until` and `bury_window` markers. It does not mention details like date formatting or sorting, but for a simple read-only listing tool the disclosed behavior is sufficient.

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

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

One dense Chinese sentence delivers the operation, parameter semantics, output markers, and usage context without waste. The most important behavior is front-loaded, and every clause adds value.

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 low-complexity tool with two optional parameters and no output schema, the description covers the essential behavior and return markers. It lacks notes on ordering or the exact meaning/format of `bury_window`, but the agent has enough information to call the tool and interpret a basic response.

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%, so the description must compensate for both parameters. It does: `days` is explained as the number of future days, and `as_of` is explained as an optional reference date replacing today. A concrete date format example would make this a 5.

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 returns events for the upcoming `days` days from today or a specified `as_of` date, with `days_until` and `bury_window` markers. This specific verb-resource pairing distinguishes it from calendar siblings like calendar_month and calendar_range, which imply different time-window scopes.

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 gives clear context for when to use the tool: it is the core endpoint for the login dashboard's upcoming-events view, returning future events relative to today or `as_of`. It does not explicitly name alternative calendar tools or exclusion conditions, so it falls just short of full guidance.

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 provided, the description bears the burden of explaining behavior. It adds useful domain context by naming the monitored signals and interpreting capital flight as a crash precursor. Still, it does not disclose data source, update cadence, whether historical series or latest snapshot is returned, or limitations.

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

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

Two compact sentences, front-loaded with the monitoring subject and signals, followed by a high-value interpretive warning. No filler or redundant restatement of tool name.

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 low-complexity tool with one optional parameter and an output schema, the description covers core inputs and purpose. The main gap is the lack of differentiation from similarly named capital-flow siblings, though this is partially captured in other dimensions.

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 single parameter focus already has a complete schema description ('apac/china/global'), so schema coverage is 100%. The tool description adds no additional meaning about parameter values, though its APAC focus aligns with the default value.

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 states a specific verb '监测' and resource '亚太资本流动方向', enumerating concrete component signals (exchange rates, FX reserves, FDI net inflows). However, it does not differentiate itself from close sibling tools such as capital_tracking or capital_flows_snapshot, so it stops short of a 5.

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

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

No guidance on when to choose this tool over capital_tracking, capital_flows_snapshot, or northbound_funds is provided. The warning about capital flight implies an early-warning use case, but this is not made explicit enough to route an agent correctly.

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?

描述揭示了“拉取并落盘”这一副作用，且无注解覆盖，这是有价值的行为披露。但input-schema中force参数已提到“绕过缓存强制重新拉取并落盘”，描述并未在结构化字段之外增加更多行为细节，也未说明刷新频率、覆盖机制或失败影响。

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?

描述为一句紧凑的句式，先给出核心动作“拉取并落盘”，再用冒号列出多维内容，最后说明用途。没有任何冗余信息，全部句子均承载有效信息。

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?

对于无必填参数、存在输出schema的复合快照工具，描述已覆盖用途、数据维度、副作用及使用场景。“社保/国家队代理指标”略显笼统，但不影响agent判断是否调用及如何调用。

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?

输入参数force在schema中已有100%覆盖的说明（绕过缓存强制重新拉取并落盘），描述本身没有增加额外参数语义。按规则schema覆盖率高时给予基线3分。

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?

描述以明确的动词“拉取并落盘”搭配资源“资金面多维动向”，并具体列出两融、北向/南向、公募ETF、社保/国家队等维度，清楚说明工具的复合快照性质。虽未直接点名与兄弟工具的区别，但多维组合本身已与单一指标类工具（如northbound_funds、margin_balance）形成区分。

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?

描述明确说明“用于个股速览待机页”，给出了清晰的使用场景和上下文。但没有提及不适用场景或替代工具选择的排除条件，属于“有明确上下文、无排除说明”的层级。

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 of behavioral disclosure. It only lists data categories and says '获取' (fetch), but does not mention data recency, update frequency, source limitations, or any other behavioral characteristics beyond the basic read operation.

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

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

The description is a single sentence with the key action and data categories front-loaded. The trailing phrase '外部机构反响与资金流向综合数据' is somewhat redundant with the enumerated items, but the overall length is appropriate and efficient.

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?

An output schema exists, so return values do not need to be described. However, there are no annotations and the description lacks context on data scope, source, or update behavior, leaving noticeable gaps for an agent deciding whether this tool fits the task.

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 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it does not elaborate on the market values or symbol format, which are already documented in the input 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 a specific verb ('获取' / obtain) and a specific resource: individual stock capital flows, institutional research records, and institutional holdings details. It is easy to tell it focuses on per-stock data versus sector or market-level siblings, though it does not explicitly name any sibling 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 gives no guidance on when to use this tool versus the many closely related capital-flow siblings such as capital_flow_monitor, stock_sector_fund_flow_rank, or industry_capital_flow. No exclusions, alternatives, or selection conditions are 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'generates a chart' and does not disclose that the tool likely writes a file via output_path, whether it depends on pre-existing Juglar data, or what happens when data is missing. No side effects or operational implications are communicated.

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 a single, front-loaded sentence with no filler or redundant wording. It is concise and immediately communicates the core purpose, although the brevity comes at the cost of missing useful context.

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 two-parameter chart-generation tool with no annotations and opaque parameter semantics, the description is incomplete. It omits the data source, file-writing behavior, and the relationship to sibling Juglar tools. Even if an output schema exists, the invocation behavior and prerequisites remain unclear.

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%, and the description adds no meaning to either parameter. 'limit' is entirely unexplained, and 'output_path' is only interpretable through its default value. An agent cannot determine valid ranges, units, or rational choices beyond relying on the defaults.

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 states a specific verb ('生成') and resource ('朱格拉周期分析图'), with a parenthetical defining the economic concept. It distinguishes itself from other cycle chart tools by naming the Juglar cycle specifically, though it does not explicitly contrast with the related data tools like juglar_cycle or data_juglar.

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 given about when to use this tool versus alternative cycle tools or data tools. There are no prerequisites mentioned, such as whether cycle data must be collected or cached first, and no exclusions are stated. Usage must be inferred entirely from the name and the action verb.

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 carry the full behavioral burden. It only says a chart is generated; it does not disclose side effects, file-writing behavior, data sources, whether it is read-only, or what the chart contains. The output_path parameter hints at file output, but the description never confirms it.

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 a single short sentence with no wasted words and the core purpose is front-loaded. However, it is so terse that it provides no supporting structure or additional context, so it is concise but slightly underspecified.

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 tool with two undocumented parameters, no annotations, and many closely related siblings, this description is not complete enough. An agent still needs to guess parameter meaning, output behavior, and when to choose this over similar cycle/chart tools. The presence of an output schema helps but is not referenced or leveraged.

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 schema has 0% description coverage, so the description must compensate for the undocumented 'limit' and 'output_path' parameters. It does not explain what 'limit' limits or what format/path 'output_path' expects, leaving the agent unable to infer parameter semantics.

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 states a specific verb ('生成' = generate), a specific resource ('基钦周期' = Kitchin cycle), and the output type ('分析图' = analysis chart). This clearly distinguishes it from sibling cycle tools such as chart_kondratiev_cycle, chart_juglar_cycle, and data_kitchin.

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 like kitchin_cycle, data_kitchin, or the other chart_*_cycle tools. No exclusions, prerequisites, or selection conditions are mentioned.

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?

没有annotations，描述需承担更多责任。它披露了会生成图表、包含PCA指数和主周期标注、保存为PNG以及可选方法，但未说明是否覆盖已有输出文件、数据来源、网络/缓存依赖或运行行为。

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?

一句话内前置了核心操作和输出格式，随后列出可选方法，没有冗余内容。每个信息点都服务于工具选择与调用。

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?

对于生成图表的低复杂度工具，描述已覆盖用途、输出格式、图表内容和可选方法，且schema提供了全部参数细节、默认值和输出schema。缺少的覆盖行为和数据源说明不算关键缺口。

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覆盖率为100%，method、focus_from、output_path均有默认值和说明。描述中的方法选项只是重复schema信息，没有在schema之外增加参数语义，因此按基准3分评定。

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?

描述明确给出了具体动词和资源：生成康波周期分析图并保存为PNG，还说明了图的内容（PCA合成指数+主周期标注）。这使其与data_kondratiev等纯数据工具以及chart_kitchin_cycle等其他周期图工具清晰区分。

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?

描述隐含了使用场景：需要生成康波周期图表时使用。但没有明确说明何时应该选择本工具而非data_kondratiev、kondratiev_cycle或其他chart_*系列工具，也没有说明pca/wavelet/bandpass方法各自适用的情形。

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?

没有提供任何注解，因此描述承担全部行为披露责任。描述仅说明'生成图表'，未提及是否覆盖已有文件、数据来源、计算所需时间、图表格式或失败条件。对于无注解的绘图工具，行为透明度严重不足。

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?

单句描述没有冗余信息，简洁性本身合格。但这是'过简'而非精炼——一句话只传达了核心动作，缺少任何使用场景或参数说明，信息密度虽高但不足以支撑正确调用。

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?

工具属于庞大家族（有chart_kondratiev_cycle、chart_kitchin_cycle、chart_juglar_cycle、kuznets_cycle、data_kuznets、data_kuznets_extended等），具备输出schema和2个可选参数，但描述仅有一句话。未说明图表数据来源、与kuznets_cycle/data_kuznets的分工、输出行为，对一个需要选择合适工具的场景来说完整性明显不足。

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描述覆盖率为0%，描述必须补偿参数含义，但描述对limit和output_path只字未提。虽然参数名暗示了'数量限制'和'输出路径'，且默认值给出了合理提示，但agent无法确知limit限制的是什么（数据点数？周期数？）以及output_path是否会被覆盖。描述完全未补偿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?

描述明确包含具体动词'生成'和资源'库兹涅茨周期分析图'，且附注'(房地产周期)'帮助理解概念。虽然与chart_kondratiev_cycle、chart_kitchin_cycle等同族图表工具能通过周期类型区分，但未说明与kuznets_cycle（数据工具）的区别，缺少显式的兄弟区分。

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?

完全没有提供任何使用时机或替代方案的指引。在大量周期相关兄弟工具（chart_kondratiev_cycle、chart_juglar_cycle、kuznets_cycle、data_kuznets、data_kuznets_extended）并存的情况下，agent无法判断何时该选本工具而非data_kuznets获取数据或chart_kondratiev_cycle绘制其他周期，也没有说明先取数据再绘图的工作流。

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 present at all, so the description carries the full burden. It implies a read-only data retrieval with '获取' but does not disclose any side effects, aggregation behavior, latency, rate limits, or output characteristics. For a composite tool that likely pulls from multiple sources, this lack of behavioral transparency is a significant gap.

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

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

The description is a single concise sentence with no filler, front-loading the 'composite skill' nature and then listing the three diagnostic dimensions. It is appropriately sized and easy to parse, though it could carry more useful information without becoming verbose.

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?

With no output schema and no annotations, the description must explain what the tool returns and how to interpret it. It names three aspects (technical, fundamental, news) but does not specify the output structure, whether it returns a score/rating, or how the result relates to the input parameters. This is incomplete for an agent deciding whether this tool is the right fit.

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 100%: both 'symbol' and 'market' have descriptions, so the schema already defines the parameters. The description adds no parameter-specific semantics, only mentioning the three diagnostic dimensions at a high level, which aligns with the baseline score of 3.

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 states a clear verb ('获取' / obtain) and a specific resource: comprehensive diagnostic data covering technical, fundamental, and news aspects. This conveys the tool's purpose and conceptually distinguishes it from single-faceted siblings, though it does not explicitly say the tool is for stocks, relying on the tool name and title.

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

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

No usage guidance is provided. The description does not indicate when to prefer this tool over alternatives such as individual_info, stock_quote, or the crypto/pm composite diagnostics, nor does it state any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It states that the tool returns combined diagnostic data, but it does not disclose aggregation behavior, potential latency from multiple underlying sources, failure modes, or whether the operation is read-only. This is a meaningful gap for a composite 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?

The description is a single efficient sentence with the key components front-loaded: one-click, cryptocurrency, technicals, sentiment, and AI report. Every part contributes meaning, and there is no redundant filler.

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?

Despite having only one simple parameter, this is a composite diagnostic tool that likely returns rich and varied output. There is no output schema, and the description does not explain what the returned diagnostic data contains, how it is structured, or how it differs from individual crypto metric tools. The description is too thin for an agent to know what to expect.

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

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

The input schema already provides 100% coverage with a clear description of the 'symbol' parameter and a default value. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

Description states a clear verb and resource: '一键获取' comprehensive diagnostic data covering technicals, sentiment, and AI reports. It conveys the tool's aggregating nature but does not explicitly differentiate it from sibling tools like crypto_prices, crypto_sentiment_metrics, or composite_stock_diagnostic.

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 when a broad crypto diagnosis is desired, as opposed to a single metric. However, it gives no explicit when-to-use guidance, exclusions, or references to alternative sibling tools such as binance_ai_report or crypto_sentiment_metrics.

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 of behavioral disclosure. It usefully adds OKX as the data source, restricts scope to perpetual contracts, and explains the sign convention. However, it does not mention the funding-rate interval (e.g., 8-hourly), whether the data is current or historical, or the units/format of the returned value.

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 a single dense sentence with no redundant wording. It front-loads the main purpose and immediately adds the key interpretive detail, making it highly efficient.

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?

With no annotations and no output schema, the description is the only source of behavioral context. It adequately conveys what the tool does and the source, but it omits details an agent might need, such as the effective period behind the rate and the response shape. For a one-parameter read-only tool, this is minimal 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?

Schema coverage is 100%: the single 'symbol' parameter is already documented with format examples (BTC, ETH, BTC-USDT). The description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description clearly states the tool gets the OKX perpetual contract funding rate with a specific verb ('获取') and resource. It also clarifies that a positive rate means longs pay shorts, which distinguishes it from other crypto data tools like crypto_prices or crypto_open_interest.

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 gives no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. While the purpose is clear, the absence of any comparison or usage context leaves an agent to infer the applicability.

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 of behavioral disclosure. It conveys a read-like action ('获取') but does not explain whether the data returned is current or historical, the time range, units, or any rate/response characteristics. This is minimal behavioral context.

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

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

The description is a single efficient sentence with no filler or repetition. It is appropriately sized for a one-parameter tool, though it is sparse and could convey slightly more useful context without becoming verbose.

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 simple one-parameter read tool, the description is minimally viable: it names the data source and resource type. However, with no output schema, the description does not clarify the return shape (e.g., current value vs. series), which is a notable gap for a data-retrieval tool.

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

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

Schema description coverage is 100%, and the single optional symbol parameter is adequately documented with a default and format examples. The tool description itself does not add parameter meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description states a specific verb (获取/get) and a specific resource (Binance perpetual contract open interest data), which clearly differentiates it from sibling tools like crypto_funding_rate, crypto_prices, and futures_positions. The title and description are consistent and unambiguous.

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 futures_positions or crypto_funding_rate. There are no stated conditions, exclusions, or references to other tools, so the agent must infer usage context.

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 supplied, the description carries the burden and does convey non-mutating retrieval and standardized output fields. However, it does not disclose the concrete return structure (e.g., OHLCV field names), ordering, timezone, or any API constraints, leaving meaningful behavioral details unspecified.

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?

A single sentence that is front-loaded with the resource and action, with no wasted words. The output-behavior clause also earns its place given the lack of an output schema.

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 simple read-only fetcher with fully documented optional parameters, the description is usable. However, with no output schema and no annotations, the vague 'standardized market fields' does not fully equip an agent to interpret the response without additional discovery.

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 documentation covers 100% of the three parameters with defaults and allowed values, so the baseline is 3. The description adds no parameter-specific meaning beyond characterizing the output as standardized K-line data.

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 uses a specific verb ('获取') and names a precise resource: OKX crypto historical K-line data. The historical-K-line scope clearly separates it from crypto sentiment, funding-rate, open-interest, and current spot price siblings.

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 explicitly states the context in which the tool applies: retrieving OKX cryptocurrency historical K-line data. It does not name alternatives or state exclusions, but the historical scope gives a clear condition of use without requiring much inference.

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 behavioral disclosure burden. It only says the tool retrieves data; it does not disclose whether results are snapshots or time series, how '主动买卖数据' is defined, whether authentication or rate limits apply, or what the response structure looks like.

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 a single sentence with no filler or repetition. It front-loads the key identifying information and every word contributes to understanding the tool's scope.

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 there is no output schema and no annotations, the description is too thin to fully support correct invocation. It does not explain the meaning of '主动买卖数据', the relationship between inst_type and long/short ratio, the expected output format, or the inconsistency between the default period '1h' and the documented granularity '1H'.

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 100%, so each parameter already has a description and the baseline is 3. The tool description adds context about OKX sentiment data but does not clarify parameter-specific details, such as the casing mismatch between the default '1h' and the documented '1H', or whether SPOT is meaningful for the leverage long/short ratio.

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 names a specific verb '获取' and a specific resource: OKX cryptocurrency leverage long/short ratio and active buy/sell data. This makes its purpose clear and distinguishes it from related siblings like crypto_funding_rate, crypto_open_interest, and fear_greed_index, which cover different metrics.

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?

There is no guidance about when to use this tool versus alternatives such as crypto_funding_rate, crypto_open_interest, or sentiment_side. The description simply states what data it returns and provides no exclusions, preferred contexts, or routing hints among the many crypto-related sibling 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 present, and the description only states the action without disclosing side effects, required permissions, or data source. The verb '查看' suggests read-only behavior, but this is not explicitly stated.

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

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

The description is a single, concise sentence with no filler. It is front-loaded with the action and resource, making it ideal for a zero-parameter tool.

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?

An output schema exists, so return-value details are not needed. However, the description does not clarify what '周期数据' encompasses or distinguish when to use this tool instead of the generic 'cache_status' sibling, leaving a minor contextual 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 tool has zero parameters, and schema coverage is effectively 100%. Since there are no parameters to document, the description doesn't need to add parameter-level details; the baseline for zero-parameter tools is 4.

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

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

Description uses specific verb '查看' (view) and resource '周期数据缓存状态' (cycle data cache status), clearly indicating a read operation. It implicitly differentiates from sibling 'cache_status' by adding the 'cycle' qualifier, though it doesn't explicitly name the alternative.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'cache_status' or when it would be inappropriate. The description simply states what it does without any contextual usage cues.

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 discloses that the tool writes to a local SQLite cache, but it does not mention potential side effects such as overwriting existing cache data, whether the collection is incremental, network/rate-limit implications, or that the operation may take a long time. This is a meaningful transparency gap for a mutation-like 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?

The description is a single focused sentence in Chinese that states the action, target, and purpose. It is front-loaded with the verb and resource, contains no redundant words, and every phrase contributes meaning.

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 low complexity (0 parameters) and the presence of an output schema, the description covers the basic what and why. However, it is incomplete for an agent deciding whether to invoke it: it does not clarify what '全部周期指标' includes, how to verify cache freshness beforehand, or what the tool returns beyond the schema. A bit more workflow context would make it 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?

The tool has zero parameters, and schema description coverage is effectively 100% vacuously. Per the baseline for 0-parameter tools, the description does not need to add parameter details. It adds no semantic information about parameters, but none is required.

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 a specific verb (预采集/pre-collect), a resource (全部周期指标数据/all cycle indicator data), and a destination (本地 SQLite 缓存/local SQLite cache). This distinguishes it from sibling cycle-analysis tools like cycle_detect or cycle_phase, and from cache-status tools like cycle_cache_status.

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 phrase '避免每次分析重新拉取' (avoid re-fetching for each analysis) implies the tool should be used before analysis as a cache-warming step. However, it does not explicitly state when not to use it, mention alternative tools (e.g., cycle_cache_status to check freshness), or provide workflow context.

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 provided, the description carries the full burden, and it does reasonably well: it reveals the algorithmic pipeline (multiple spectral methods plus three-level voting) and the kind of outputs produced. It does not mention edge cases or limitations, but the operation is clearly non-mutating analysis of supplied data, so the core behavioral traits are transparent.

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 a single dense sentence that front-loads the purpose ('频谱周期检测') and then packs the method, voting mechanism, and outputs with no filler. Every phrase contributes useful information.

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 an output schema exists, return values do not need to be elaborated further. Together with the schema, the description covers input format, selectable methods, target period range, and outputs. The main gap is lack of sibling differentiation, but that is a usage-guidance issue rather than a completeness gap for invoking the 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?

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description adds little parameter-specific meaning beyond referring to the input time series and naming the default methods, which matches but does not exceed the schema. Baseline 3 is appropriate.

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 states a specific action—running FFT/ACF/wavelet/MUSIC spectral analysis plus three-level voting on an input time series—and names concrete outputs (detected period, confidence, current phase). It is clear and distinct from sibling tools by method and resource, though it does not explicitly contrast itself against similar cycle-related siblings.

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 phrase '对输入时间序列' makes it clear the tool is for analyzing user-provided time series data, which implies its usage context. However, the description gives no explicit guidance on when to prefer this tool over alternative siblings such as cycle_collect, cycle_nesting, or cycle_phase, nor any exclusions.

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 carries the full burden. It discloses output content and format (composite Z values + phase sequence, JSON array), implying a read-only data retrieval. It does not mention data source, freshness, caching, rate limits, or other behavioral caveats, so transparency is adequate but not rich.

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

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

A single well-structured sentence front-loads the resource name and then packs the cycle composition, output content, output format, and use cases without filler. Every clause earns its place.

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 no-parameter tool, this description is sufficient for an agent to invoke it correctly. The output schema can cover detailed field structure, while the description establishes what the data represents and what it is used for. The main missing context is explicit routing among sibling cycle tools, which is more a usage than a completeness 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 tool has zero parameters, so no parameter explanation is required and the baseline is 4. Schema coverage is 100% and the description adds value by explaining what the returned payload represents rather than repeating parameter details.

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 identifies the resource as four-cycle nested data combining Kitchin/Juglar/Kuznets/Kondratiev, with composite Z values and phase series, distinguishing it from sibling single-cycle tools. It also names intended downstream use (nesting chart and Gantt chart). However, it lacks an explicit fetching/returning verb, so it stops just short of a 5.

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

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

The phrase 'used for cycle nesting chart and Gantt chart' gives a clear but implicit use context. It does not explicitly state when to prefer this tool over siblings like data_kitchin, cycle_phase, or chart_kondratiev_cycle, nor does it give exclusion guidance.

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 provided, the description carries the full burden and does disclose the core processing behavior: CF bandpass filtering followed by phase inference. However, it does not mention side effects, assumptions about the input, or the interpretation of the phase output, leaving some behavioral context implicit.

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 a single front-loaded sentence with a clear purpose prefix and a concise method clause. It contains no filler, but it is terse enough that some usage and output guidance is omitted.

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 the schema covers all parameters and an output schema exists, the description is adequate for making a basic call. However, with many cycle-related sibling tools and no usage or behavioral guidance, the description is not fully complete for confident tool selection.

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 already describes all three parameters with 100% coverage, including the meaning of low_yr, high_yr, and the CSV format. The description adds only high-level algorithm context rather than parameter-level details, so it stays at the schema-driven baseline.

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 states a specific operation ('周期相位判断') on a defined resource ('输入时间序列') and explains the method (CF band-pass filter + phase inference). It is distinguishable from sibling cycle tools by focusing on phase determination rather than collection or nesting, though it does not explicitly name an alternative.

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 given on when to use this tool versus siblings such as cycle_detect, cycle_nesting, cycle_collect, or the various named cycle tools. The description only says what the tool does, not under what conditions it should be selected.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool returns a JSON array of stage positioning data, without explaining source, coverage, freshness, or whether it is a simple read operation. This is minimal behavioral information beyond the tool's purpose.

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 a single concise sentence with no filler. The core resource and output format are front-loaded, making it easy for an agent to parse quickly.

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 zero-parameter data retrieval tool with an output schema present, the description is mostly sufficient for invocation. It could be slightly more complete by indicating how this differs from the extended variant, but the basic context is adequate.

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 tool has zero parameters and the schema description coverage is 100%. Since there is nothing for the description to clarify about parameters, the baseline of 4 applies.

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 identifies the tool as retrieving Juglar cycle (fixed capital investment cycle) stage positioning data as a JSON array, using a specific verb and resource. It does not explicitly differentiate itself from sibling 'data_juglar_extended', but the core purpose is unambiguous.

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

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 related siblings such as data_juglar_extended, juglar_cycle, or chart_juglar_cycle. There is no mention of alternatives, exclusions, or preferred use cases.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the data source, time period, frequency (annual), and output format (JSON array), which are useful. However, it does not explain what 'extended' adds over the base version, nor any caveats about data completeness or how missing values are handled.

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 a single compact sentence that front-loads the core identity (Juglar cycle FRED extended version), then lists the included indicators, frequency, and output format. Every phrase carries information, with no filler or redundancy.

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 zero-parameter data-retrieval tool with an output schema, the description covers the essential invocation context: source, period, indicators, frequency, and format. It is slightly incomplete in not clarifying the exact difference between the extended and non-extended versions, but this is a minor 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 tool has zero parameters, so there is no parameter semantics gap. The baseline of 4 applies because no parameter documentation is needed; the description instead conveys the data content, which is the only meaningful semantic information for invoking this tool.

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 identifies the resource as the extended Juglar cycle dataset from FRED and specifies its content (non-residential fixed investment, private fixed investment, GNP, capacity utilization). The 'extended' qualifier and the period '1929~' help distinguish it from the plain data_juglar sibling, though no explicit action verb like 'retrieves' is present.

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 is given about when to use this tool versus alternatives such as data_juglar, data_kitchin_extended, or chart_juglar_cycle. The name and content imply use for extended FRED-based Juglar cycle data, but there is no clear when-to-use or when-not-to-use statement.

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 communicates that this is a read-only retrieval operation returning a JSON array, which is basic behavioral context. However, it does not disclose data source, freshness, caching behavior, or any limitations of the returned data.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, the object, and the output format efficiently.

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 zero-parameter tool with an output schema, the description is minimally sufficient for invocation. However, in a large sibling family with data_kitchin_extended and multiple cycle tools, it does not clarify which tool is the right choice or what distinguishes this variant from similar ones.

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 tool has zero parameters and an empty input schema, so the baseline is 4. The description does not need to explain parameter semantics, and it does not introduce any misleading parameter-related information.

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 uses a specific verb ('获取' / obtain) and names the resource ('基钦周期各阶段定位数据'), and it also states the output form (JSON array). However, it does not explicitly differentiate itself from closely related siblings such as data_kitchin_extended, kitchin_cycle, or chart_kitchin_cycle.

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?

There is no guidance about when to use this tool versus the many cycle-related siblings. No alternatives are mentioned, no conditions are given, and no exclusions are stated. The agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the output format (JSON array), annual frequency, starting year, source (FRED), and the three constituent indicators. It does not discuss update behavior or missing-data handling, but for a parameterless read-only data tool these are the key behavioral facts.

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 a single compact sentence that front-loads the tool identity, then provides period, components, frequency, and format. Every phrase carries meaningful information with no filler or repetition.

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 no-parameter data retrieval tool with an output schema present, the description is complete enough: it gives the identity, time range, source, frequency, and content of the returned JSON array. An agent can select and invoke this tool correctly based on the description alone.

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 zero properties, and 0-parameter tools have a baseline of 4. There are no parameters to document, and the description instead usefully clarifies what the returned data contains.

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 identifies the resource as the extended FRED-based Kitchin cycle dataset, specifies the period (1919~), the component series (industrial production, manufacturer inventories, M2), frequency, and output format. It lacks an explicit retrieval verb and does not name the sibling data_kitchin, but the 'extended' qualifier and component list make the tool's role reasonably distinct.

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?

There is no explicit statement of when to use this tool versus alternatives such as data_kitchin or kitchin_cycle. However, the description implies its usage context: it is the extended/annual-frequency Kitchin dataset with extra M2 coverage, so selection is left to inference rather than direct guidance.

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 carry the transparency burden. The verb '获取' and '原始数据' signal a read-only data query and the parenthetical describes the returned series type, but the description does not explicitly address side effects, caching, or how the method parameter alters the result.

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 a single well-formed sentence with no filler; the core resource is stated immediately and the parenthetical adds a relevant qualifier. It earns its place efficiently.

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 tool is simple: one optional parameter, no required inputs, and an output schema is already present. The description plus schema is sufficient to invoke the default behavior, though richer sibling differentiation and method-output clarification would make it fully self-contained.

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 100% for the single optional parameter, so the baseline is 3. The description adds that the output is a PCA synthetic index series, but it does not clarify whether that label applies to all method choices (pca/wavelet/bandpass) or only the default.

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 states a specific verb ('获取') and resource ('康波周期原始数据'), with the useful qualifier 'PCA合成指数序列'. It clearly identifies a data-retrieval tool, implicitly distinct from chart/analysis siblings, though it never explicitly names kondratiev_cycle or chart_kondratiev_cycle as alternatives.

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?

There is no guidance on when to use this tool versus its many siblings. No exclusions, prerequisites, or alternative tool names are given; '获取康波周期原始数据' only implies a use case rather than explaining 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?

Because annotations are absent, the description must carry the full behavioral burden. It only states that a JSON array of stage positioning data is returned; it does not disclose whether the operation is read-only, whether the data is pre-collected/cached, or what happens when data is unavailable. This is thin disclosure for a tool with no annotation safety net.

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?

Exactly one short sentence states the action, resource, and output type with no filler. It is front-loaded and appropriately sized for a parameterless data retrieval tool.

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 output schema covers return structure, and zero parameters remove input ambiguity. However, the description omits the relationship to several sibling cycle and data tools and provides no caveat about data availability, leaving moderate context gaps for tool selection.

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 zero parameters and full coverage of that empty set, so there is no parameter ambiguity to resolve. The description reinforces what data is being requested, which is sufficient since no arguments need to be supplied.

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 specifies a concrete action (获取) and resource (库兹涅茨周期各阶段定位数据) and even states the return format (JSON array). It clearly identifies the tool as a data-retrieval operation, but it does not explicitly differentiate it from closely named siblings such as data_kuznets_extended or kuznets_cycle.

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 about when to use data_kuznets instead of data_kuznets_extended, kuznets_cycle, chart_kuznets_cycle, or cycle_collect. There is also no mention of prerequisites, such as whether cycle data must be collected or cached first, so the agent must infer usage context from the tool name alone.

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

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

With no annotations, the description carries the behavioral burden. It discloses the return format (JSON array), frequency (annual), time coverage (1947 onward), source (FRED), and the set of included indicators, which is substantial for a read-only data retrieval tool. It does not mention caching, update cadence, or units, but those are secondary given zero parameters and an available output schema.

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

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

A single compact statement packs the source, cycle name, extension status, start year, three constituent indicators, frequency, and output format without filler. Every segment contributes meaningful selection and invocation information.

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?

Since the tool takes no parameters and an output schema is already available, the essential information for selecting and invoking it is present: dataset identity, source, time range, constituents, frequency, and format. No invocation-critical detail 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?

The input schema is an empty object with no required or optional parameters, so there are no parameter semantics to explain; the 0-parameter baseline of 4 applies. The description's listed terms describe the returned data rather than input arguments, which is appropriate here.

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 identifies a concrete dataset: the Kuznets cycle FRED extended edition starting in 1947, covering US house prices, housing starts, and residential investment, delivered as an annual JSON array. It is distinguishable from sibling cycle tools by its 'extended' scope, FRED source, and listed series, but it is phrased as a noun phrase rather than an explicit verb like 'returns'.

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 gives no explicit guidance on when to use this tool versus data_kuznets, kuznets_cycle, chart_kuznets_cycle, data_kitchin_extended, or data_juglar_extended. The word 'extended' implies a relationship to a basic version, but there is no stated when-to-use or when-not-to-use context.

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 carries the full burden, and it does disclose key behavior: it 'directly outputs' a repayment-capability verdict based on the listed metrics. It does not explain methodology, caveats, or data sources, so it is not fully transparent.

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 entire description is a single dense sentence that front-loads the core purpose and expected result, with no filler or repetition of schema details.

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 one-parameter tool with a fully documented input schema and an output schema present, the description covers purpose, scope, and expected output adequately. Nothing essential for invoking or interpreting the tool 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?

The single 'countries' parameter is fully documented in the JSON schema, including country codes, default value, and comma-separated format. The description only echoes this with '各国' and adds no new parameter-level meaning, so the schema-coverage baseline of 3 applies.

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 states a specific operation: comparing debt sustainability across countries using clearly listed indicators (government debt/GDP, FX reserve adequacy, inflation), and defines the expected output as a direct solvency verdict. This distinguishes it from raw macro-data tools in the sibling list.

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

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

The use case is implicit but clear: use this tool when the user asks for cross-country debt sustainability comparison or who can/cannot repay debt. It does not explicitly name alternative tools or say when not to use it, so it stops short of a 5.

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

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

With no annotations at all, the description carries the full transparency burden and does meaningful work: it discloses the time-dependent behavior (盘中实时 vs 最近交易日收盘) and names the data provider (腾讯). This is exactly the kind of behavioral trait an agent needs to interpret results correctly. It stops short of covering failure modes or what 'auto' mode resolves to, but the core behavioral disclosure is strong.

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?

Two tight sentences: core function first, then source/mode behavior, then return format. No filler or repeated title content. The return-format snippet is slightly dense but earns its place since there is no output schema to reference.

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 3-parameter tool with zero annotations, 0% schema coverage, and no output schema, the description leaves major gaps: parameter semantics are entirely absent, and there is no statement about what happens with an empty domain or how the domain string is matched. The return-shape disclosure helps, but an agent would still be guessing on how to fill in dtype and domain.

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%, yet the description explains none of the three parameters. 'domain' (what string to pass, how it matches a domain), 'dtype' (what values it accepts, what 'auto' means), and 'limit' (max count? pagination?) are all opaque. At zero schema coverage, the description was obligated to compensate and did not.

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 specifies a clear verb+resource+outcome: parse associated domains (概念/行业/板块) into constituent stocks, with a concrete data source (Tencent) and return shape. It is reasonably distinguishable from siblings like industry_sw_constituents and stock_concepts by its domain-agnostic scope (concept/industry/sector) and real-time/close mode, though it never explicitly names a competing sibling.

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 when to use the tool: during trading hours it returns real-time snapshots, after close it returns the latest close. This gives context on invocation timing, but provides no explicit guidance on when not to use it or which alternatives (e.g., industry_sw_constituents for strict SW-industry constituents) to choose instead.

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 carries the full burden of behavioral disclosure, and it only reveals that the chart is '简单的' (simple) and trend-oriented. Worse, the claim that output is generated 根据提供的价格列表 misdescribes behavior, since the schema accepts market+symbol, implying the tool fetches data itself. Nothing is said about data sourcing, default time range, or failure modes.

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

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

One short 24-character sentence that front-loads the primary action. It is easy to scan and every word carries intent; the only blemish is the misleading '价格列表' phrase, which is a content accuracy problem rather than a structural one.

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?

With no output schema and no annotations, the description must do more than it does. It leaves unresolved whether the tool fetches data via symbol/market or expects a price list, gives no sense of the chart's timeframe (there is no date parameter), and doesn't relate itself to draw_crypto_chart. For a charting tool this is noticeably thin.

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 100%, so the schema already fully documents market (with default and allowed values) and symbol, which normally justifies a baseline of 3. However, the description actively introduces a phantom '价格列表' (price list) parameter that doesn't exist in the schema, which can mislead an agent into looking for a non-existent argument.

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 states a specific action — 根据提供的价格列表生成一个简单的 ASCII 走势图 (generate a simple ASCII trend chart) — which is more than a tautology of the title. However, it doesn't explicitly distinguish itself from the near-identical sibling draw_crypto_chart, and it references a '价格列表' (price list) input that doesn't exist in the schema, muddying what the tool actually consumes.

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 given. The phrase 用于直观展示趋势 only implies a generic visualization use case and provides no exclusions, no prerequisites, and no pointer to when to prefer this over draw_crypto_chart or text-based data tools like stock_quote or individual_hist.

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 of behavioral disclosure. It only mentions generating an ASCII chart, but does not clarify whether it fetches live data, what the chart represents, whether it has limitations, or what the exact output shape is. This is a minimal disclosure for a tool with no annotation support.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core function efficiently, though it may be too sparse to be considered excellent given the absence of usage and behavioral context.

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 simple two-parameter drawing tool, the schema covers the inputs well and the description states the output format. However, with no output schema and no annotations, the description does not mention data source, supported symbol scope beyond examples, or how this tool relates to sibling chart tools, leaving meaningful 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 100%, with both parameters (bar and symbol) described with defaults and allowed formats. The tool description itself adds no extra parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 states a specific verb ('生成' - generate), a concrete resource ('加密货币走势图' - cryptocurrency trend chart), and the output format (ASCII). This makes the tool's primary function clear and distinguishes it from generic chart or data tools, though it does not explicitly differentiate it from the sibling draw_ascii_chart.

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?

There is no guidance about when to use this tool versus alternatives such as draw_ascii_chart, crypto_prices, or crypto_composite_diagnostic. The description provides no context, exclusions, or conditions, so an agent must infer usage entirely from the tool name and schema.

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 carries the full burden. It transparently describes the data-fetching and aggregation behavior: pulls top-10 holdings, counts overlapping holdings, calculates average weight and co-rate, then outputs the top co-rate targets. It does not mention rate limits, data freshness, or error behavior, but for a read/analysis tool this is reasonably complete.

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 compact and well-structured: one sentence describes the input-process-output chain, and a second explains the purpose. There is no redundant or filler content; every clause contributes meaningful information.

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 is complete enough for a two-parameter tool with no output schema. It specifies inputs, computation logic, and the type of output. It lacks explicit notes on return structure or invalid code handling, but these are not critical for basic invocation.

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 100%, so the baseline is 3. The description reinforces that etf_codes refers to same-theme ETFs/funds and mentions top-10 holdings, but it does not add significant semantic detail beyond the schema, and top_n is not elaborated in the description.

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's input (a set of same-theme ETF/fund codes), the operation (fetch top-10 holdings, compute co-held counts, average weight, and co-rate), and the output (the core targets with the highest co-rate). It does not explicitly contrast with siblings like etf_crowding_alert or fund_holdings, so it stops short of full differentiation.

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

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

The description gives a clear use case: identifying genuinely co-held core assets in same-theme products and avoiding duplicate allocation. It does not provide explicit when-not-to-use guidance or name alternatives, but the context is sufficient for an agent to understand the intended application.

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 provided, the description carries the full burden, and it delivers: it discloses the scoring formula (共同率权重、平均权重集中度、被持有 ETF 数量), the semantic interpretation (共同率越高 = 抱团越紧 = 潜在踩踏/反转风险越大), and the output shape (拥挤度分档 低/中/高 + 预警提示). It does not cover data-source freshness, fetch behavior, or empty-result edge cases, but for a read-only analysis tool the core behavioral semantics are well disclosed.

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 single paragraph contains no fluff — every sentence carries signal (basis, function, risk interpretation, scoring components, output format) and the core action is front-loaded in the first clause. It could be slightly better structured with explicit labeling of inputs vs. outputs, but it is dense and economic.

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?

There is no output schema and no annotations, so the description must explain return values; it does state the return format (分档 低/中/高 与预警提示) and the full decision logic behind it. For a moderately complex 2-parameter tool this is largely complete, though an example alert or a note on data dependency (what happens if the provided ETFs share no holdings) would close the remaining 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?

Schema description coverage is 100%, so the baseline is 3: the schema already documents etf_codes (comma-separated ETF codes with example) and top_n (number of targets, default 15). The description adds marginal meaning by stating the analysis targets 共同率最高的标的, which clarifies that top_n selects the most crowded targets, but it does not compensate beyond that.

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 states a specific resource (同 ETF 共同持仓核心标的), a specific verb (输出拥挤度评分与反转预警), and defines its scope (共同率最高的标的). The analytic function — crowding scoring plus reversal alerting — is clearly distinct from data-retrieval siblings like etf_core_holdings or fund_holdings, but it never names a sibling or explicitly states what it is not, so it falls short of full 5 differentiation.

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?

Usage context is implied rather than stated: by describing crowding-score computation and risk interpretation, the description signals it is for institutional-clustering/reversal-risk assessment on same-theme ETFs. However, there is no explicit when-to-use statement, no when-not-to-use guidance, and no named alternatives (e.g., etf_core_holdings for raw holdings lists), leaving the agent to infer routing.

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 carries the full burden; it does disclose that this is a read-only fetch and that the value lies on a 0-100 scale. It omits the data source, freshness/cache behavior, and return shape beyond the range, so behavioral transparency is only partial.

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?

A single short sentence that is front-loaded with the key facts and contains no redundant wording. Given the absence of parameters, this is appropriately 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?

For a zero-argument tool, the description is nearly adequate, but with no output schema it leaves ambiguity about whether the result is a bare number or a structured payload with sentiment labels and timestamps. This is a small but real completeness 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?

There are zero parameters, so the baseline of 4 applies. The description adds useful domain context by specifying the cryptocurrency market and the 0-100 scale, which is all that is needed here.

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?

States a specific verb (获取) and resource (加密货币市场恐惧贪婪指数) plus the 0-100 range, so the purpose is immediately clear. However, it does not name or distinguish itself from related crypto sentiment tools such as crypto_sentiment_metrics, so it lacks explicit sibling differentiation.

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