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

With no annotations provided, the description carries the full burden and discharges it richly. It discloses deterministic rule-based behavior ('零 LLM、零模糊匹配'), fallback plan when no intent matches, multi-intent priority by table order, specific error codes (E1001) for invalid inputs, and the behavior of ignoring invalid column_hints references while noting them in the summary.

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 long but well-structured with clear sections for parameters, intent table, return value, and examples. Most content earns its place; minor meta-information like 'v1.2.0 方案 B 落地' and '与 statlab_mcp/docs/design/11_analysis_plan.md 同步维护' is useful context but not strictly needed for invoking the 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?

Given the tool's complexity, the absence of an output schema, and zero schema descriptions, the description is remarkably complete. It covers all parameters, the full intent list, fallback behavior, the result structure with keys like chosen_methods and tool_calls_plan, a summary template, and two representative examples. An agent has enough to select and call this tool correctly without external documentation.

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 fully. It explains each parameter's meaning, requiredness, mutual exclusivity constraints, valid value domains for column_hints ('数值|类别|日期'), and error behavior for invalid values. This goes well beyond the raw type-only 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 opens by identifying the tool as an orchestration-layer analysis plan generator ('编排层 · 分析计划生成') and immediately clarifies it converts a decision tree into a deterministic rule tool that '只出计划不执行' (only plans, does not execute). This clearly distinguishes it from all the sibling execution tools like hypothesis_test, linear_regression, and describe_statistics, which actually perform the analyses.

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 strong usage boundaries: it is for generating plans, execution is left to the outer agent calling first-layer tools, and it documents parameter preconditions (question required, file_path/inline_data mutually exclusive, both missing is legal, both provided triggers E1001). It stops short of naming specific sibling alternatives for when-to-use-not, but the orchestration-versus-execution contrast is explicit.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly guarantees that anomalies are only reported and not removed, documents constant-series behavior, states that threshold is ignored for IQR, and discloses method-specific criteria such as rolling window sizes and index remapping. This is substantially more than the schema or annotations reveal.

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

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

The description is well structured with headers, bullets, and a front-loaded purpose, but it is longer than necessary. Internal maintenance notes, doc-sync statements, and deprecation rationale go beyond what is needed for tool selection and invocation, even though most content is technically relevant.

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?

Input formats, method behavior, and inline-data alternatives are well covered, which is enough to invoke the tool correctly. However, there is no output schema and the description never explains the return value structure, so an agent cannot fully anticipate how anomaly results will be represented.

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

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

The input schema has 0% description coverage, yet the description thoroughly explains all parameters: file_path, date_col/value_col, method variants, threshold semantics and defaults, plus inline_data accepted shapes and the file_path/inline_data exclusivity. It fully compensates for the empty schema descriptions.

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

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

The description clearly identifies the tool as time-series anomaly detection and names the concrete methods (STL, IQR, rolling z-score). It is scoped to the time-series group and a simple example shows the intended call shape, which distinguishes it from generic outlier detection or statistical test 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 gives rich parameter-level guidance but no explicit guidance on when to choose anomaly_detect over sibling tools such as outlier_detect. There is no when-to-use/when-not-to-use statement or discussion of alternatives, so an agent must infer usage context from the domain label and method list.

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

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

With no annotations, the description carries full behavioral burden and succeeds: it discloses a deterministic procedure, exact library calls, post-hoc method selection, and a known limitation (Games-Howell p-values omitted, CI-only judgment, '诚实披露'). It also states that assumption violations warn but do not block execution.

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

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

The description is well-structured with clear sections: parameters, deterministic flow, example, and inline data. It is longer than typical, but the length is justified by the complexity of the statistical behavior and the implementation details needed for correct invocation.

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

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

The description covers data formats, parameter constraints, algorithm fallbacks, post-hoc details, inline_data modes, and example usage, making it nearly complete for invocation. It does not spell out the full return object (e.g., F-statistic, p-value fields) and does not explicitly mark group_col/value_col as required, which matters given there is no output schema.

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

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

Schema description coverage is 0%, and the description compensates fully by defining every parameter: file formats for file_path, grouping semantics and the 2–20 group bound for group_col, numeric requirement for value_col, alpha ∈ (0,1), and the two accepted shapes of inline_data plus the one-of constraint with file_path.

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 leads with '方差分析' (ANOVA) and '统计推断组', naming the exact statistical operation and grouping it among inference tools. The detailed procedure (f_oneway, Welch, Tukey, Games-Howell) distinguishes it clearly from sibling tests like chi_square_test, nonparametric_test, and hypothesis_test.

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?

It provides clear usage context: compare a numeric value across 2–20 groups, with explicit prerequisites (Levene, Shapiro) and automatic selection of classic vs Welch ANOVA. It does not explicitly name alternative tools and the conditions for choosing them, so it falls short of a 5.

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

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 performs multiple model fits, has a 10000-point result cap with truncation, reports MAPE=null for near-zero actuals, and appends a limitations disclaimer. It also reveals internal details like _prepare_series and leakage prevention. This is exceptional transparency.

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

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

The description is long but densely packed with valuable information, organized with clear headers (参数, 门槛链, 指标, 局限声明, 示例). It front-loads the core purpose before diving into details. Some redundancy exists (e.g., E1001 mentioned twice), and the docstring maintenance note is meta-information that could be trimmed, but every section 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?

Given 7 parameters, no output schema, no annotations, and a complex statistical tool, this description covers validation rules, output metrics, error codes, edge cases, and usage examples. It even addresses potential concerns like computational cost and data leakage. This is as complete as a text description can reasonably be.

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 explains each parameter with types, defaults, constraints, and semantic alignment with time_series_forecast. For method, it enumerates all three options and their behaviors. The only minor gap is that inline_data's exact shape is deferred to SPEC.md, but the description gives enough context to use 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 begins with a clear statement: '时序组 · 滚动回测' and immediately explains it is a rolling-window backtest for time_series_forecast, computing MAE/RMSE/MAPE. It distinguishes itself from the sibling time_series_forecast by emphasizing it provides '历史表现' credibility. The purpose is specific and unmistakable.

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 this tool is for validating time_series_forecast, and notes it shares preprocessing with forecast. It provides parameter constraints, validation thresholds (E1010, E1005), and even notes inline_data is an alternative to file_path. It gives explicit examples and explains fallback behavior for seasonal_naive. This is comprehensive usage 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, the description carries the full behavioral burden and exceeds it: deterministic pipeline, binning rule, error conditions for unique values, Fisher exact fallback with OR/df=null, Cramér's V formula, expected-frequency caveat, and the 'association ≠ causation' warning. An agent can predict side effects and 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?

Purpose, parameters, deterministic flow, example, and inline-data note are laid out in a logical, front-loaded order with negligible redundancy. The only nonoperational sentence is the docstring-synchronization maintenance note, preventing a perfect 5.

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 no annotations and no output schema, the description covers input constraints, preprocessing, test selection, effect size, edge-case errors, conclusion template, and caveats. It even names the statistics an agent can expect in the result (chi2, expected frequencies, OR, df, Cramér's V).

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

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

Schema coverage is 0% and has four nullable params with no descriptions. The tool description documents file formats for file_path, the mutual exclusivity and two accepted shapes of inline_data, and the required existence plus auto-binning behavior for col_a/col_b. This is exactly the operational semantics the schema lacks.

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 statistical operation ('卡方独立性检验') and a specific resource (association between two categorical columns), immediately distinguishing it from generic inference siblings. The example call and the '两列类别变量' requirement make the scope 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?

It gives clear input context: two categorical columns are needed, numeric columns get auto-binned, and file_path/inline_data are mutually exclusive. However, it never explicitly says when to prefer this tool over siblings such as nonparametric_test or correlation_matrix, so alternative routing is left to 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so extensively: it states that only numeric columns are used, non-numeric columns are excluded and listed, StandardScaler z-score normalization is applied, KMeans is run with fixed random_state and n_init, centroids are inverse-transformed, cluster sizes must accompany centroid interpretation, and silhouette scores are computed with k-1/k+1 comparisons. This gives the agent a clear, detailed picture of the tool's behavior.

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

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

The description is well-organized into labeled sections for parameters, methodology, example, and inline data, making it scannable. Some content is meta or redundant, such as the docstring-sync note and 'tool 14' identifier, but the overall structure earns its length by providing substantive algorithm and usage detail.

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

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

The description is largely complete for selecting and invoking the tool: it explains the parameters, gives a working example, and describes the preprocessing and model configuration. However, it does not explicitly describe the return format/structure of the results, and it defers some inline-data limits to an external SPEC document, which may not be accessible to the agent at invocation time.

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

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

The input schema provides almost no semantic detail (0% coverage), but the description compensates fully: file_path supports csv/tsv/xlsx/json, k must satisfy 2 <= k <= sample_count-1 with error handling, and inline_data supports two concrete shapes and is mutually exclusive with file_path. Each parameter gets meaningful guidance beyond the bare type declarations.

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 KMeans clustering for modeling tasks, which goes beyond the generic name 'cluster_analysis' by naming the exact algorithm. It also differentiates from sibling modeling tools like linear_regression, pca_analysis, and hypothesis_test. However, it does not phrase the purpose as a direct agent-facing action or explicitly state what kind of output the tool produces.

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 an example and states the algorithm configuration, but it never tells the agent when to choose this tool over alternatives or when not to use it. There is no explicit mention of use cases, comparisons to sibling tools, or exclusion conditions.

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

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

With no annotations provided, the description bears the full burden of behavioral disclosure, and it does so thoroughly: ddof=1 for sd, deterministic default_rng(42) with 1000 resamples, percentile method, reproducibility independent of global RNG, Chinese error messages, and degenerate point intervals for constant columns. This is far beyond a minimal purpose statement.

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 long but well organized into parameter, boundary, example, and inline-data sections, making it skimmable and largely information-dense. A small amount of noise comes from the meta sentence about docstring/design-doc synchronization and from repeating schema defaults.

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?

It covers input selection, method math, defaults, error conditions, degenerate cases, and reproducibility, which is enough for an agent to invoke the tool correctly. The main gap is that it does not describe the return object structure, and there is no output schema to compensate.

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 prose must explain all parameters, and it does: file_path accepted formats, column numeric requirement, confidence in (0,1), method choices with formulas, and inline_data's two accepted shapes. It also communicates the mutual exclusion between file_path and inline_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 explicitly identifies this as the confidence-interval tool for the statistical inference group and defines the two supported methods with formulas (mean_t and bootstrap_median), so an agent can determine exactly what computation is performed. It is unambiguous and detailed even though it does not contrast with siblings.

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

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

It gives clear usage context: when to use file_path vs inline_data, valid method choices, boundary conditions, and error cases. However, it does not explicitly state when confidence_interval should be chosen over related siblings like hypothesis_test or effect_size, so an explicit exclusion/alternative statement is missing.

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

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

No annotations are present, so the description carries the full behavioral burden, and it does so extensively: scipy pairwise .statistic/.pvalue, pandas corr rejected for lacking p-values, kendall/kendalltau alias behavior, BH-FDR correction on computable upper-triangle pairs, constant-column nulls, and numeric-column error thresholds. It also discloses the success/error response envelope.

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 organized into labeled sections—params, return, 口径, examples, inline_data—and most content is operational detail earned by the absence of annotations and output schema. Meta sentences like 'docstring = agent 使用说明书' and '红队裁决 11' add maintenance context rather than invocation value, so it is not zero-waste.

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?

It covers all essential invocation information: complete result structure, null semantics, correction unit, pairwise-complete handling, method aliases, examples, and rejection conditions. The only material deferral is inline-data scale/type rules pointed to an external SPEC document, which may not be available to the 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 description coverage is 0% and there are no enums, so the description is the only source of parameter meaning. It documents all four parameters with formats, allowed values, defaults, and side effects, including inline_data's two accepted shapes and mutual exclusivity with file_path.

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 the tool as a correlation matrix in the data-exploration group and details its method options and result fields (correlation, p_value, n_pairwise), so the tool's job—computing pairwise correlation matrices—is clear. It lacks an explicit verb like 'calculates' and does not state how it differs from siblings such as plot_heatmap or hypothesis_test, so it stops just short of the highest tier.

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 implied by the tool's placement in the data-exploration group and by constraints like '数值列 >20 拒绝' and '<2 列拒绝', which tell an agent when the input is unsuitable. It never explicitly states when to choose correlation_matrix over a sibling tool and gives no 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?

With zero annotations, the description carries the full burden and meets it thoroughly: it discloses a deterministic six-branch decision tree with exact thresholds (95% conversion success, min(50, rows×20%)), the numeric-before-date ordering rationale, dirty_count semantics, invalid-date handling (2024-02-30), success/error envelope shapes, and the UNC-path rejection. Even the implementation-vs-design-doc deviation is flagged so the agent is not misled.

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 long but densely structured into labeled sections (参数/返回/判定树/示例/inline 数据) with the purpose front-loaded in the first line. The decision tree and return schema earn their length because they encode observable behavior an agent needs to predict outputs; the only mild waste is meta-maintenance prose about doc-sync and the external SPEC.md cross-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 complex classifier with a bare schema (no param descriptions, no enums, no output schema, no annotations), the description is essentially self-sufficient: it documents the full nested result structure, all six classification outcomes with thresholds, both input modes, and an example call. The only residual ambiguity is whether at least one of file_path/inline_data is required, since both schema properties are nullable — a minor edge case.

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, and it does exhaustively: file_path gets supported formats (csv/tsv/xlsx/json), a local-only constraint, and UNC rejection; inline_data gets mutual exclusivity with file_path, both accepted shapes (records array or {header, rows} object), a version marker (v1.2.0), and a pointer to SPEC.md §12 for limits. Both parameters gain operational meaning the bare schema cannot convey.

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 opens with a precise verb+resource statement — "数据探查组 · 列类型识别" (data exploration group · column type identification) — and reinforces it with a complete decision tree classifying columns as numeric/integer/date/mixed/category/text. This clearly distinguishes it from siblings like describe_statistics, missing_report, and correlation_matrix, which profile data along different axes.

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 "数据探查组 · 工具 2" header plus the detailed detection semantics imply this is an exploration-stage tool used before statistical analysis, but no sentence explicitly states when to choose it over a sibling or when not to use it. There is no alternative routing toward describe_statistics, missing_report, or analysis_plan, 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, the description carries full responsibility and delivers thoroughly: local-path-only restriction, UNC rejection, success/error shapes, exact statistical definitions (linear q1/q3, ddof=1, scipy skew/kurtosis), and edge-case semantics for missing/constant/small/non-numeric columns. This makes runtime behavior highly predictable.

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 long but organized into labeled sections (parameters, returns, definitions, edge cases, example, inline data), and the detail is largely earned because there is no output schema or annotations. Some meta text like 'docstring = agent 使用说明书' is unnecessary, keeping it just below top tier.

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?

It covers input formats, return schema, error shape, statistical formulas, and edge cases, which is substantial for a complex tool without annotations or an output schema. It falls short of 5 only by referencing external docs for inline-data size limits/type domains and lacking an explicit selection policy.

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?

Both parameters are given meaning far beyond the bare schema: file_path is restricted to local csv/tsv/xlsx/json paths (UNC rejected), and inline_data is described as a mutually exclusive alternative supporting records arrays or {header, rows} objects. Size limits/type domains are deferred to SPEC.md, so it is not perfectly self-contained.

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 '数据探查组 · 描述性统计' and details its output schema (n_rows, n_columns, per-column statistics), so an agent can tell it computes descriptive statistics. It is clear on action and resource, but it never names sibling tools or explicitly states what it is not (e.g., not a hypothesis test), so it misses the strongest 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?

It implies usage via '数据探查组' and an example invocation, and explains file_path vs inline_data mutual exclusivity, but it gives no explicit when-to-use vs alternatives or exclusions. An agent must infer when descriptive statistics is appropriate rather than a hypothesis test or correlation analysis.

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 and does so thoroughly. It discloses exact formulas, normal-approximation CI construction with 1.96*se, explicit labeling of '正态近似', empirical thresholds, simplifications (no bootstrap CI, no distribution tests, cliff_delta lacks a paired version), and the deterministic paired-matching semantics without ID columns.

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 dense and information-rich, with formulas, defaults, simplification notes, and an example all earning their place. It is long but well organized by labeled sections. Minor verbosity exists around docstring maintenance references and the inline_data section, which could be tightened without losing 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?

Given the tool's complexity, six parameters, no output schema, and no annotations, the description is nearly complete: it covers inputs, method semantics, constraints, and output caveats. The main gap is that it does not explicitly specify the shape or keys of the returned result object, only indicating that the CI will be labeled as '正态近似'.

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 and does fully compensate. Every parameter is explained: file_path and inline_data are explicitly alternatives, group_col and value_col have constraints, method lists valid options with defaults, and paired describes the equality requirement and matching convention. This goes well beyond the bare schema types.

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 an effect-size calculator for statistical inference, and lists the supported methods (cohens_d, hedges_g, cliff_delta) plus the input roles (group_col, value_col). It is specific about what the tool computes, though it does not explicitly contrast itself with sibling tools such as hypothesis_test or nonparametric_test.

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 operational constraints (e.g., group_col must have exactly 2 groups, paired samples must have equal sizes) and notes simplification choices, but it provides no explicit guidance on when to choose this tool over alternatives like hypothesis_test, anova_test, or confidence_interval. The usage context is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden and is substantially transparent: it discloses train_test_split(0.25, random_state), fitting on the training set, permutation on the test set, impurity via feature_importances_, balanced class weights, fixed seeds, and the 'importance≠causality' footer. It does not explicitly state whether the tool has side effects or auth requirements, but the detailed computational behavior makes its functioning 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?

The description is well structured into parameter documentation, hard threshold, implementation details, example, and inline-data guidance. It is long but most sentences carry useful information; only the maintenance note and external SPEC.md pointer add limited direct invocation 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?

The description is rich and includes an example, thresholds, and algorithm details, but it leaves some important gaps: the schema marks all parameters optional yet the description never explicitly states that file_path or inline_data and target are required. With no output schema, the return format is only vaguely described as a ranking plus footnote, and some constraints are deferred to an external SPEC.md that an MCP agent may not access.

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 compensates thoroughly: every parameter has type, default, and semantic constraints, e.g., n_estimators>=10, n_repeats>=1, method choices, and inline_data forms including mutual exclusivity with file_path. This is far more than the schema provides.

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 computing feature importance via random forest, with explicit classification vs regression behavior and an output of feature-importance ranking plus a causality footnote. It is specific about the resource and operation, though it does not explicitly distinguish itself from sibling modeling tools such as linear_regression or pca_analysis.

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 is implied by the name and description, and the tool gives internal guidance such as choosing permutation vs impurity and treating targets with <=20 classes as classification and continuous targets as regression. However, it does not explicitly say when to choose this tool over sibling alternatives, nor does it state when not to use it apart from the n<50 rejection threshold.

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 delivers: it discloses Welch's t-test as a hard specification with Welch-Satterthwaite df, the Shapiro pre-check for 3<=n<=5000 that warns but does not block, always two-sided CI construction, Cohen's d formulas per design, and the exact conclusion wording template. This is exceptional disclosure of statistical behavior beyond what any structured field could convey.

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 long but well-sectioned into parameters, methods, examples, and inline-data notes, with critical constraints front-loaded and worked usage examples included. It loses a point for meta-content that doesn't help invocation, such as the doc-sync maintenance note and the deferral of inline_data limits to an external SPEC.md section.

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 9-parameter tool with no annotations and no output schema, the description covers parameters, statistical methods, pre-check behavior, fallback paths, output highlights (CI, Cohen's d, conclusion template), and examples. The remaining gaps are the absence of a full result-structure specification and error-handling behavior, plus reliance on external docs for inline_data limits.

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 fully compensate, and it does: every one of the 9 parameters is documented with types, defaults, and constraints (column must be numeric, group_col exactly 2 groups with n>=2, alpha in (0,1), sample2_col paired-aligned). It even documents inline_data's two accepted shapes and its mutual exclusivity with file_path, which the bare array/object union in the schema leaves opaque.

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 opening line identifies it as "统计推断组 · 假设检验（工具 6，核心实现）" — a hypothesis testing tool in the inference group — and the body enumerates the three supported variants (one_sample, independent, paired) with their statistical methods. This clearly separates it from sibling tools like normality_test, anova_test, and chi_square_test, which address different inferential questions.

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 concrete selection context: group_col is required and must have exactly 2 groups for independent, sample2_col for paired, and mu0 for one_sample. It also explicitly names nonparametric_test (Wilcoxon/Mann-Whitney) as the fallback when the Shapiro pre-check is violated. It stops short of full when-not routing against siblings like anova_test for 3+ groups, so it earns 4 rather than 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?

没有 annotations，描述承担了全部行为披露义务：明确“绝不修改输入文件”、输出写入 reports/imputed/ 并返回绝对路径、全缺失列会跳过并如实记录、文件写入有 utf-8-sig 和公式注入转义、固定附加局限声明。这些信息远超基本说明，行为非常透明。

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?

描述结构清晰，按功能、参数、边界、返回、示例分段，信息密度高且可读性强。扣一分是因为夹杂了“工具 28”“docstring 同步维护”等元信息，对工具调用本身不是必须，略有冗余。

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、无 annotations、5 个参数且行为复杂的条件下，描述覆盖了参数语义、返回结构、错误码、边界行为、输出路径、局限声明和示例，足以让 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 描述覆盖率为 0%，描述完全补偿了参数语义：逐一解释了 file_path、columns、strategy、value、inline_data 的含义、默认值、约束和错误码，还说明了 mean/median 对 ±Inf 的处理及 constant 与 value 的依赖关系，比 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?

描述首句明确点名“缺失值插补”和“数据探查组·确定性整治工具”，指出处理对象是缺失值、方法是规则插补、输出是新 CSV，并与 missing_report 明确区分。工具用途一眼可辨，不会与同组分析/绘图类工具混淆。

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?

描述明确指出 missing_report 是互补工具，且限定“只做规则插补，不做智能推断”，等于给出了使用边界；还在参数部分说明了 file_path 与 inline_data 二选一、value 仅在 constant 策略下使用，提供了清晰的选型和使用条件。

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 behavioral burden and does so thoroughly: it discloses statsmodels OLS matrix interface (no formula), one-hot encoding with drop_first=False plus mapping output, zero-variance column removal, listwise dropna with row-count reporting, rejection when n is too small, VIF>10 flagging, residual diagnostics, and top-level __image__ plots.

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 organized into clear labeled sections (参数, 口径, 示例, inline 数据) and is dense with useful information. Minor overhead exists in maintenance notes like 'docstring = agent 使用说明书...' and '工具 12，核心实现,' which do not help an agent invoke the 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 complex modeling tool with no output schema and no annotations, the description is highly complete: parameter semantics, edge-case behavior, examples, and inline_data support are all covered. It does not define the full return-object shape, but it names key outputs (GOF, VIF, residual diagnostics, image placement) well enough for 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 0%, and the description compensates fully by documenting all six parameters: file formats for file_path, continuous-target constraint for target, one-hot behavior for features, add_constant consequence for GOF, alpha threshold semantics, and the inline_data record/header-rows shapes with a file_path/inline_data mutual-exclusion rule.

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 the tool as '线性回归' using statsmodels OLS, with a continuous dependent variable (target) and feature list, which clearly conveys a model-fitting operation. It does not explicitly contrast itself with sibling logistic_regression, but the '连续因变量（数值列）' constraint implies the intended use case.

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 through parameter semantics ('target (str): 连续因变量' and '类别列自动 one-hot'), and examples show typical calls. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as logistic_regression, leaving the agent to infer selection criteria.

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 handles it well. It discloses deterministic duplication for class_weight='balanced', the absence of built-in statsmodels weights, fixed random seeds, stratified split behavior, convergence warnings on perfectly separable data, and the caveat that accuracy is affected by class imbalance.

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 long but well-structured with clear sections for parameters, outputs, examples, and inline data. The maintenance note 'docstring = agent 使用说明书...' is meta and not directly actionable, but the remaining content is dense and relevant. It is appropriately sized for a 7-parameter tool with nontrivial behavior.

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

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

The description covers inputs, defaults, outputs, error behavior, class-weight implementation, and convergence warnings, which is strong given no output schema exists. It lists the five required outputs but does not specify their exact JSON structure or types, and some inline-data limits are deferred to an external SPEC document.

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 all 7 parameters. It does: file_path, target, features, test_size, random_state, class_weight, and inline_data are each explained with types, defaults, constraints, and special behaviors. This far exceeds the bare schema and gives an agent enough to construct valid calls.

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 the tool as '建模组 · 逻辑回归' and details its binary classification role, target/feature requirements, and fixed outputs. It clearly distinguishes it from sibling modeling tools like linear_regression by focusing on binomial targets and OR/p-values, though it never states an explicit verb phrase like 'fits a logistic regression model'.

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 concrete usage constraints: target must be exactly 2 classes, features must be numeric, one-hot encoding is not performed, and non-numeric features raise errors. It also explains the inline_data vs file_path choice. It does not explicitly name alternative tools for other scenarios, but the binary-classification framing makes the intended use clear.

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 behavioral burden and succeeds. It discloses the success/error envelope, defines missing as empty cells/strings converted to NaN, specifies all-missing columns rate=1.0 with a note, explains pairwise missing patterns, caps patterns at 10 sorted descending, and sets patterns=[] when no missing values exist.

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 long but well-organized into parameters, return format, missing definitions, example, and inline-data notes. It loses a point for the meta-maintenance sentence ('docstring = agent 使用说明书...') which is not actionable for an agent, though the core content is front-loaded and non-redundant.

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 lacking an output schema and annotations, the description is self-sufficient. It provides input modes, constraints, a full text-based result schema, error response shape, and edge-case rules, giving an agent everything needed to invoke the tool and interpret 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?

Schema description coverage is 0%, so the description must compensate fully. It enriches file_path with supported formats (csv/tsv/xlsx/json) and the local-path-only constraint, and inline_data with two accepted shapes (records array or header/rows object) plus the mutual-exclusivity rule. This goes far beyond the bare type-only 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 identifies the tool as a missing-value report ('缺失报告') and details the output structure with counts, rates, and patterns. It does not explicitly call out sibling alternatives, so it falls just short of full differentiation, but the purpose is unmistakable.

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 offers parameter-level constraints such as '仅接受本地路径（拒绝 UNC）' and inline_data being mutually exclusive with file_path ('二选一'), but it never states when to choose this tool over sibling tools like impute_missing. No use-case scenarios or alternative recommendations are provided.

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

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

With no annotations, the description carries full weight and delivers exact SciPy functions/methods, tie handling, zero-difference removal, continuity correction, effect-size formulas and direction conventions, fixed conclusion wording, sample-size boundaries, and Chinese error behavior. This goes far beyond what the input schema offers.

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 text is long but organized into clear sections (parameters, statistical conventions, boundaries, example, inline data) with front-loaded parameter semantics. Minor internal metadata such as '工具 26' and doc-sync notes add noise but do not prevent quick scanning.

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 complex 9-parameter tool with no output schema, the description covers inputs, edge cases, and behavioral conventions thoroughly. The main gap is the absence of an explicit return-value contract (field names/shape), although the conclusion template and effect-size definitions partially compensate.

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

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

Schema coverage is 0% and there are no required parameters, so the description is the only source of parameter meaning. It explains every parameter, defaults, allowed values, conditional requirements (e.g., column/sample2_col only for wilcoxon), alpha bounds, alternative applicability, and inline_data shape.

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 the tool as nonparametric inference (统计推断组 · 非参数检验) and enumerates the three supported tests: Wilcoxon, Mann-Whitney, and Kruskal-Wallis. This makes the operation and resource clear, and the concrete test names distinguish it from sibling tools like anova_test or chi_square_test.

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?

It maps each supported test to its data scenario (paired, two independent groups, multiple groups) and states conditional parameter requirements. It does not explicitly contrast the tool with sibling hypothesis tests or tell the agent when a parametric alternative would be preferred, though it notes nonparametric tests generally have lower power.

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 behavioral burden and meets it: it enumerates exact method-switching thresholds, output keys, the fixed 0.05 alpha and normal decision rule, and all Chinese-error boundary cases. This goes well beyond the schema and gives the agent a precise model of tool 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?

The description is well structured with labeled sections and front-loads the core purpose in the first line. It is longer than necessary because the maintenance/docstring note and the SPEC.md pointer are meta-information rather than invocation guidance, but the density of actionable detail justifies most of the length.

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 complex inference tool with no output schema and no annotations, it covers parameters, outputs, errors, and an example. The main gap is that inline_data limits and typing are deferred to an external SPEC.md document rather than summarized inline, which leaves some behavior undocumented for an agent that cannot follow that reference.

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

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

Schema description coverage is 0%, but the description documents all four parameters: file_path formats, column numeric requirement, method enum values with auto logic, and inline_data's two accepted shapes plus its mutual exclusivity with file_path. It fully compensates for the empty 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 identifies the tool as a normality test in the statistical inference group and specifies the resource being analyzed (a numeric column). It is distinguishable from siblings by its name and function, but it does not explicitly contrast itself with related tools like nonparametric_test or hypothesis_test, so it stops short of full sibling differentiation.

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

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

It provides detailed method-selection rules (auto -> Shapiro-Wilk for n<=5000, D'Agostino-Pearson for 5000<n<=100000, and an error for larger samples), boundary conditions, and a working example. However, there is no explicit statement of when to prefer normality_test over sibling tools such as nonparametric_test or describe_statistics, so the usage context is implied rather than directly stated.

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 excels: it discloses that outliers are never deleted, details edge cases for n<4 and constant columns, explains that non-numeric columns are skipped, truncates display at 100 outliers, and describes the plot file path and top-level __image__ return field with no base64. This is far beyond typical 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?

The description is well-structured with labeled sections for parameters, methodology, behavior, plot output, example, and inline data, and it front-loads the tool's purpose. It is somewhat verbose and includes maintenance metadata about docstring sync that is not directly needed for invocation, but the extra detail is organized and mostly 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?

Given there is no output schema and no annotations, the description covers invocation parameters, algorithmic edge cases, output artifacts, and inline-data alternatives comprehensively. An agent has enough context to call the tool correctly, understand its edge-case behavior, and interpret the returned result including the __image__ field.

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, and it does thoroughly. file_path is documented with accepted formats and local-only restriction; method is constrained to iqr with default; inline_data is described with two supported shapes, mutual exclusivity with file_path, and a spec reference for limits. This fully supplies the meaning missing from the bare schema.

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

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

The description clearly identifies the tool as outlier detection ('异常值检测') and specifies the IQR algorithm with concrete lower/upper bound definitions. It distinguishes the method from z-score scenarios by pointing to rolling_zscore, but it does not explicitly differentiate this tool from the sibling anomaly_detect, so sibling differentiation is incomplete.

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 explicit when-not guidance: only iqr is supported, and z-score scenarios belong to rolling_zscore in the time-series group. It also states that outliers are never removed automatically, only reported. However, it does not give a clear explicit comparison with anomaly_detect or a general 'use this for tabular univariate outlier detection' rule, so guidance is strong but not fully comprehensive.

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 zero annotations provided, the description carries the full disclosure burden and meets it thoroughly. It reveals data filtering (numeric columns auto-excluded), preprocessing (StandardScaler), the non-randomness caveat (random_state=42 is interface consistency only), the exact loading de-standardization formula (component vector × feature std dev), the plot placement (__image__ top level), error behavior (out-of-bounds n_components yields Chinese error), and the interpretive guardrail that principal components are not business factors. This is exemplary transparency.

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

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

The description is long but earns its length: sections for parameters, methodology (口径), example, and inline data are clearly delineated and scannable. The purpose is front-loaded in the first line. Minor deductions for the meta sentence about docstring maintenance synced with design docs and the '工具 15' organizational label, which are contextually useful but not strictly behavioral 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?

For a 3-parameter tool with no output schema and no annotations, the description covers inputs, constraints, preprocessing, computation, outputs (variance rates, cumulative, loadings, plot), and caveats. It is slightly incomplete in not specifying the exact return structure (e.g., field names of the result object beyond the plot key), and it defers scale limits and type-domain details to SPEC.md section 12 rather than stating them inline. Still, an agent has nearly everything needed to call and interpret the tool 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%, so the description must fully compensate, and it does for all three parameters. file_path gains supported formats (csv/tsv/xlsx/json); n_components gains the bound 1 <= n <= min(samples, features) plus error behavior; inline_data gains the two accepted shapes (records array or {header, rows} object), the v1.2.0+ version gate, and exclusivity with file_path. Every parameter receives meaning far beyond the bare string/integer/array types in 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 opens with '主成分分析' (Principal Component Analysis) and then specifies the exact pipeline: numeric-only columns, StandardScaler standardization, sklearn PCA, variance-explained and cumulative outputs, de-standardized loadings, and a loading plot. This is a specific verb+resource with distinct methodology that clearly separates it from statistical-test siblings like t-test, anova_test, and cluster_analysis. The '建模组 · 核心实现' framing also situates it within the modeling workflow.

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: the tool is for PCA in the modeling group, and a concrete example (pca_analysis("samples/clean.csv", n_components=2)) demonstrates invocation. The inline_data vs file_path mutual exclusivity is documented. However, no explicit when-to-use guidance or named alternatives among the 29 sibling statistical tools is provided; an agent must infer when PCA is preferred over correlation_matrix, cluster_analysis, or factor-oriented analyses.

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 discloses meaningful behavior: the plot includes five-number summary and IQR outlier count, uses the same criterion as outlier_detect, and supports two inline_data shapes. However, it does not describe the return value or error behavior, which is a notable gap given there is 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 organized into a purpose line, a core behavior paragraph, and an inline-data note. It front-loads the main function and avoids fluff, though the inline-data section is somewhat verbose with the external SPEC 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?

The tool has 3 optional parameters, no output schema, and no annotations. The description covers input modes and plot contents but omits the return format, error handling, and parameter-level details such as column's format. Reliance on an external SPEC for limits reduces self-contained 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?

Schema description coverage is 0%, so the description must compensate. It explains inline_data in detail (records array or header/rows object) and its exclusivity with file_path, but it does not explicitly define the column parameter or file_path format, leaving some parameter semantics to inference.

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 plots a single-column box plot with five-number summary and IQR outlier count. It explicitly distinguishes itself from outlier_detect by noting the single-column scope and absence of an outlier export table, leaving no ambiguity about what it does.

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 explicit usage guidance: inline_data and file_path are mutually exclusive, and it directs agents to Tool 5 for outlier localization, naming the alternative and the condition. The single-column scope also implies 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 full transparency burden. It meaningfully discloses that the tool only plots rather than predicts, describes the five unified preprocessing steps via _common._prepare_series, mentions interpolation/aggregation/timezone reporting, and documents inline_data versioning and limits. It stops short of describing the actual return format or any side effects, but the core behavior is 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 compact and front-loads the key distinction (plotting vs forecasting) and the core output (raw line + 7-day MA). Some references like '工具 24' and '_common._prepare_series' are cryptic but not redundant; overall it earns its length without 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?

The description covers purpose, data source options, preprocessing behavior, and inline data formats, which is substantial for a plotting tool. Yet with no output schema or annotations, it does not explain what the tool returns (e.g., image path or rendered figure), what happens if neither file_path nor inline_data is provided, or how errors surface. These are meaningful gaps for an agent selecting and invoking the tool.

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

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 does add real semantics for inline_data: supported shapes (records array or header/rows object), mutual exclusivity with file_path, and a pointer to limits in SPEC.md. However, date_col, value_col, and file_path are left to inference from their names, and no required-combination guidance is given.

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 and resource: plotting a time-series line chart with raw values plus a 7-day moving average. It also explicitly sharpens the boundary by saying '仅作图不预测' and referencing the forecasting tool, distinguishing it from time_series_forecast and sibling plot 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?

It explicitly tells agents not to use this tool for forecasting ('预测见工具 17') and clarifies that inline_data and file_path are mutually exclusive alternatives. However, it does not explicitly contrast this tool with other plot siblings like plot_scatter or plot_histogram, so usage guidance is strong but not comprehensive.

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 discloses useful behavioral details: it uses pandas .corr() with the same formula as correlation_matrix, returns null r for constant columns, omits p-values/corrections, and accepts inline_data in two shapes. It does not explicitly state the return format or whether the plot is returned as an image/path, so it stops short of a 5.

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 with the core purpose, followed by formula, limitations, and inline-data details in a readable layout. The 'tool 23, core implementation' phrasing is mildly redundant, but the overall structure 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 tool with no annotations and no output schema, the description covers core behavior and inline-data formats well, but it omits file_path semantics and the exact return/visualization contract. The external SPEC reference helps but pushes required details outside the description.

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 does explain inline_data thoroughly: mutually exclusive with file_path, supports records arrays or header/rows objects, and references SPEC section 12 for limits. However, it gives no semantic detail about file_path beyond its existence, and the limits are deferred to an external document rather than stated.

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 opens with a specific verb and resource: plotting a pairwise Pearson correlation heatmap for all numeric columns, with r values in cells. It also distinguishes itself from correlation_matrix by noting the shared formula but explicitly no p-values or corrections, which disambiguates it from the main 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 gives clear context for when it applies (numeric-column correlation heatmap) and explicitly states what it does not do: p-values and corrections, citing a division of labor with 'tool 4'. However, the reference to 'tool 4' is not resolved by name, and there is no explicit guidance for choosing this over other plotting siblings such as plot_scatter or plot_histogram.

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 transparency burden. It does well by disclosing the binning formula, the statistics drawn on the plot, the supported inline_data shapes, and a pointer to SPEC.md for limits and type domains. It does not describe what the tool returns or how the plot is delivered, which is a minor gap.

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

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

The core purpose is front-loaded, followed by the binning rule and input format details. Some clutter exists ('工具 22，核心实现'), but overall the description is compact and 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?

The description covers core plotting behavior and inline data constraints, but it lacks return/output semantics and does not adequately explain file_path or column behavior. Since there is no output schema, some of this burden falls on the description, and it is only partially met.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning for inline_data and file_path by stating they are mutually exclusive and by describing inline_data formats. However, 'column' is only implied by 'single-column' and its null/default behavior is not explained, leaving an important parameter underdocumented.

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 this is a single-column distribution histogram and specifies what the plot displays (n/mean/std). Its identity as a histogram distinguishes it from siblings like plot_scatter, plot_heatmap, and plot_box, even without naming them explicitly.

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 is implied by '单列分布直方图' and the inline_data/file_path mutual-exclusivity note. However, there is no explicit guidance about when to choose this tool over plot_box, plot_scatter, or other visualizations, and no alternative tool is 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?

With no annotations, the description carries the full burden of behavioral disclosure and does so thoroughly: pairwise missing deletion with reporting, Pearson r and n annotation, save_plot protocol, and an absolute __image__ return path. These details reveal actual side effects and data-handling behavior beyond the schema.

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

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

The description is compact and front-loads the core purpose first, followed by protocol and inline-data details. The '工具 21，核心实现' header adds minor clutter, but the overall structure is scannable and free of empty phrasing.

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 plotting tool with no output schema and no annotations, the description covers plot contents, missing-data handling, save/return conventions, and inline-data constraints. It is slightly incomplete because it does not explicitly state that exactly one of file_path/inline_data must be set or clarify required column semantics.

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 adds real semantics for inline_data (two accepted shapes, mutual exclusivity with file_path, limits in SPEC §12), but it leaves x_col, y_col, and file_path without explanatory detail beyond their names.

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: '生成 x-y 散点图' and identifies the tool as the scatter plot in the visualization group. It also discloses key outputs (Pearson r and sample size), though it does not explicitly contrast with sibling plotting 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?

It gives useful selection context between file_path and inline_data ('二选一') and documents the inline_data shapes, but it does not say when to prefer this tool over alternatives such as plot_histogram or correlation_matrix. Usage is implied by the description rather than explicitly stated.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It states that computation is deterministic, uses exact noncentral t/normal approximations via statsmodels, defines all three modes, documents the E1001 error condition, and discloses the fixed limitation disclaimer appended to the summary.

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 long but well organized and front-loaded with purpose and usage context. Most sentences add value; only minor maintenance metadata like tool version and docstring sync status could be trimmed without hurting an agent's ability to select and invoke the 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?

Given the tool has 8 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers parameter constraints, mode selection, return structure, error behavior, and limitations, with examples that illustrate realistic calls.

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?

Input schema coverage is 0%, so the description must fully explain the parameters, and it does. Every parameter is documented with types, defaults, constraints, per-scenario meaning, and the Cohen's h conversion for two-proportion scenarios, plus examples showing parameter combinations.

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 is for power analysis and sample size calculation, and it specifies the two exact questions it answers. It adds scenario details (one_sample_t, two_sample_t, two_proportions) and a mode decision table, so it is easy to distinguish from related statistical 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?

The description gives clear context for when to use the tool: whenever the user asks how many samples are needed or what effect/power is achievable with a given n. It also provides a precise mode decision table based on which parameters are supplied, though it does not explicitly name sibling tools that should be used 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 to carry the safety/behavioral burden, the description provides rich behavioral disclosure: it names the exact underlying call including extrapolate_trend='freq', explains the auto model-selection rule, documents the all-positive requirement for multiplicative decomposition and the resulting Chinese error, and describes the output shape (component statistics, seasonal factors, four subplots). This exceeds what any structured annotation would typically provide.

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

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

The description is well-sectioned and front-loads purpose and parameters before behavior and example. It is longer than strictly necessary due to maintenance/version notes and an external-doc pointer, but those additions are minor and don't obscure the actionable content.

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 no output schema, the description covers inputs, model selection, constraints, error behavior, and high-level return content (component statistics, seasonal factors, four plots). It is slightly incomplete in that it defers inline_data scale/type limits to an external spec and doesn't enumerate the exact output fields, but an agent has enough to 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%, so the description must supply parameter meaning, and it does so for all six parameters: file formats for file_path, roles of date_col/value_col, FFT-based period auto-estimation, the additive/multiplicative/auto choices, and the two supported inline_data shapes. It also adds a mutual-exclusion rule between file_path and inline_data that the schema does not express.

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 specific operation — seasonal decomposition of a time series — with a concrete implementation (statsmodels.seasonal_decompose) and a simplified-implementation qualifier. It does not explicitly contrast itself with sibling time-series tools such as trend_analysis or time_series_forecast, so it falls just short of full sibling differentiation.

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

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

The use case is implied through the tool name, '时序组 · 季节分解', the parameter list, and an example, but there is no explicit statement of when to choose this tool over alternatives or when not to use it. The model-selection notes ('auto: 全正值 -> multiplicative，否则 additive') provide parameter-level guidance but not tool-selection 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, the description carries the full behavioral burden and does so thoroughly: it discloses auto_arima settings, the FFT-based seasonal detection rule leading to SARIMA/ARIMA, common preprocessing via _prepare_series, the constant-column mean fallback, and the output format including a top-level __image__ plot. This gives an agent a clear model of what the tool will do internally and return.

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 organized into labeled sections (参数, 口径, 示例, inline 数据) and front-loads the core purpose, but it contains meta-commentary such as 'docstring = agent 使用说明书' and '工具 17，简化实现' that does not help an agent invoke the tool. The technical content is useful, yet the opening wastes a sentence on documentation maintenance rather than tool behavior.

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

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

Given that there is no output schema, the description adequately communicates the return values (forecast + CI + chart) and key behavioral rules such as seasonal model selection and mean fallback. It does not specify the exact response JSON structure or edge-case error behavior for invalid files, but for a forecasting tool with documented parameters and an example, coverage is 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 description coverage is 0%, but the description compensates by explaining all five parameters: file_path with supported formats, date_col/value_col as date and value column names, horizon with its numeric bounds and error message, and inline_data with its two accepted shapes and exclusivity with file_path. It also includes a concrete example call.

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 时间序列预测 (time-series forecasting) and specifies the output as forecast values plus 95% CI and a historical/forecast chart, so the verb and resource are specific. However, it never explicitly distinguishes this tool from siblings like backtest_forecast or seasonal_decompose beyond the name and output description.

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 input constraints such as accepted file formats, horizon bounds, and the file_path/inline_data mutual exclusivity, which implies when the tool is applicable. It does not explicitly state when to use this tool versus alternatives such as backtest_forecast or trend_analysis, so guidance is implied rather than direct.

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

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

With no annotations, the description carries full burden and compensates well: it discloses the exact statistical formulas (kendalltau, normal approximation p), the Theil-Sen pairwise slope median, sampling behavior for n>2000 with fixed seed, and the seasonality warning. It stops short of describing exact return structure or error handling, but the core behavioral traits are covered.

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 clearly structured into sections (parameters, methodology, example, inline data) and front-loads the purpose. Some meta-commentary (docstring sync, tool number) is extraneous, but the density of useful information justifies the length.

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 no annotations, no output schema, and five undocumented parameters, the description covers inputs, methods, output values, and cautions. It references external docs for inline data limits, which is a minor completeness gap if those docs are not accessible to the agent, but overall it is sufficient for correct 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 0%, and the description compensates thoroughly: it explains file_path supported formats, date_col/value_col roles, method options with defaults, and inline_data shapes plus exclusivity with file_path. It also clarifies the statistical meaning of method choices, adding value far beyond the bare schema.

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

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

The description clearly identifies the tool as time-series trend analysis with specific statistical methods (Mann-Kendall and Theil-Sen) and output values (tau/p/slope). It differentiates from siblings by its focus on trend statistics rather than forecasting or decomposition, though it does not explicitly name alternative 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?

The description gives implementation details for method selection and clarifies the mutually exclusive file_path vs inline_data inputs, but it does not explicitly state when to use trend_analysis over sibling tools like seasonal_decompose or time_series_forecast. The 'seasonal component caution' hint implies one alternative but does not name it.

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