profile_data

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

No annotations are provided, so the description carries the full burden and it does disclose real behavioral traits: profiling is an objective-fact pass, xls/xlsx binaries are explicitly NOT supported and a CSV export is required, and the parser is chosen solely from the filename extension. It stops short of stating read-only/no-side-effect semantics, size limits, or what happens to the suspected non-data rows it reports.

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?

Front-loaded with the key routing constraint, then the return payload, then per-argument notes in a clean Args block. Slightly verbose in the middle sentence, but every clause (returned facts, unsupported xls/xlsx, extension-only filename) carries actionable information rather than restating the name.

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

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

With no output schema and 0% parameter coverage, the description accepts the full explanatory burden and delivers: it enumerates the returned fact categories, the down-stream decision they support, and the input format limitations. An agent has everything needed to invoke it correctly and interpret the result without guessing at return shape.

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 largely does: data_text is defined as raw file content with the accepted text formats (CSV/TSV/TXT/JSON) and the unsupported binary formats spelled out, and filename is clarified as only mattering for its extension. Still missing practical semantics like encoding expectations, size ceilings, and what happens when filename contradicts the actual content.

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?

Specific verb+resource ('Profile a tabular dataset') with an explicit temporal/decision scope ('BEFORE choosing a chart'), which cleanly separates it from sibling render_chart and list_chart_types. The description then enumerates exactly what facts it produces (dtype/cardinality/missingness/statistics, grain, insight signals), so an agent knows the output is analytical metadata, not a visualization.

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 states the selection condition clearly: run this before choosing a chart, and use the returned facts to decide column roles and which chart to draw. That implicitly routes the agent to render_chart afterward, but it never names render_chart or list_chart_types as the alternatives or states when not to call it (e.g., already-profiled data, non-tabular input).

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