数据画像：每列类型/去重近似数/空值率 + 数值列 min/max/avg/std/分位数（1 credit/次）。
相当于 pandas df.describe()——AI 拿它一眼看清整份数据的分布与质量。失败自动退款。
返回 {ok, format, n_rows, n_cols, profile[]}。
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | 格式 csv/tsv/json/ndjson/parquet；缺省自动识别 | |
| file_id | No | 已上传的数据文件 ID（与 data_base64 二选一） | |
| data_base64 | No | 数据文件内容 base64（与 file_id 二选一） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format, the computational cost (1 credit per call), and automatic refund on failure. It also notes that distinct counts are approximate, which is a key behavioral nuance. It doesn't explicitly state whether the tool is read-only, but the profiling nature implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the tool's purpose, lists the computed statistics, provides a familiar metaphor, states the credit cost, and specifies the return structure. Every sentence adds value, and the length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explicitly lists the return fields ({ok, format, n_rows, n_cols, profile[]}), making the tool's behavior clear. It covers purpose, usage context, cost, and failure handling. The main gap is lack of explicit guidance on when to prefer this over siblings, but overall it is quite complete for a read-only profiling 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?
The schema already covers 100% of parameter descriptions (fmt, file_id, data_base64), so the baseline is 3. The description adds no extra parameter-level semantics beyond what the schema provides; it focuses on output and behavior, which is acceptable but not additive to the parameter understanding.
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 what the tool does: it profiles data by computing per-column type, approximate distinct count, null rate, and for numeric columns min/max/avg/std/quantiles. The analogy to pandas df.describe() and the explicit list of statistics make the purpose unmistakable, and it distinguishes itself from sibling tools like data_clean or data_convert.
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 clear context on when to use the tool: to quickly understand the distribution and quality of an entire dataset ('AI 拿它一眼看清整份数据的分布与质量'). It does not explicitly name alternatives or exclusions, but the use case is well-defined and distinct from cleaning, converting, or querying siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct data operation (clean, convert, inspect, join, profile, query). There is minor overlap between data_inspect and data_profile (both provide column types and null information), but descriptions and names make the intended use clear.
All tool names follow a consistent 'data_' prefix plus a concise verb (clean, convert, inspect, join, profile, query). The pattern is uniform and predictable.
Six tools is well-scoped for a data processing toolbox. Each tool covers a core data wrangling need, and the count is neither sparse nor overwhelming.
The toolset covers the main data lifecycle: cleaning, format conversion, structural inspection, profiling, joining, and querying. No obvious critical operations are missing for common data analysis workflows.