data_type_check

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.