MCP Data Science

by AstyanM

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes with detailed descriptions, but with 102 tools some overlap exists (e.g., save_report/save_report_html, drop_low_importance/variance_filter, multiple plot_* distribution tools). An agent may occasionally struggle to pick between very similar alternatives, but descriptions usually guide correct selection.
Naming Consistency4/5
Tool names largely follow a verb_noun pattern (load_csv, drop_columns, plot_histogram, train_model), but there are notable deviations such as quality_report, variance_filter, crosstab, and one_hot_encode. The naming is mostly predictable and readable, though not perfectly uniform.
Tool Count1/5
102 tools is far beyond the typical well-scoped range. Even for a broad data science server, the sheer number overwhelms and increases selection complexity. Most of these tools could be consolidated or organized into subgroups, but the current count is extreme.
Completeness4/5
The tool set covers the full data science lifecycle: data loading, cleaning, transformation, visualization, statistical testing, modeling, evaluation, clustering, and reporting. Minor gaps exist (e.g., no time series resampling, no model persistence to disk, no advanced feature selection), but the overall coverage is remarkably complete.
Average 4/5 across 100 of 102 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It states the tool visualizes outliers and compares distributions, but does not say whether the plot is displayed, saved, or returned, nor whether it mutates any dataframe state. For a plotting tool with no structured safety metadata, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence. It consists of three sentences and an example, with no redundant fluff. The example partially repeats the prose but also illustrates a concrete invocation, making it useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more complete context. It covers purpose and grouping, but does not explain df_name and save_path, nor the display/save behavior or return value. In the context of many sibling plot tools, it also lacks differentiation, leaving notable gaps for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 missing parameter details. It explains 'column' and 'by' via prose and example, but completely omits 'df_name' and 'save_path', leaving half of the parameters undocumented in both schema and description. This partial coverage is insufficient for reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies plot_box as a box plot for outlier visualization and comparing distributions across groups, with optional grouping by a categorical column. It also explicitly notes it complements detect_outliers, but it does not differentiate from other distribution/grouping plots like plot_violin or plot_qq. Thus it is clear in purpose but lacks 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for outlier visualization and group comparisons, and mentions it complements detect_outliers with a visual perspective. However, it gives no explicit guidance on when to use this tool versus other plotting alternatives, nor does it state exclusions or prerequisites. The example shows usage but does not aid tool selection beyond the implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It says 'switch' but does not explain that this changes global session state, whether it returns a confirmation or error, or what happens if the specified name is invalid. The side effects on subsequent operations are only implied by 'current active dataframe.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the main action in the first sentence. The second sentence adds usage context ('when working with multiple dataframes') but is somewhat redundant with the first. Overall, it is efficient and free of extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description covers the basic purpose and context. However, it lacks important behavioral details like validation and side effects, and it does not explain how to identify valid dataframe names. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The single parameter 'name' is not explained beyond the schema title. The description does not clarify that 'name' should correspond to an existing dataframe name, nor does it point to list_dataframes as a way to discover valid values. This leaves the parameter underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Switch the current active dataframe.' This is a specific verb-resource pair that distinguishes it from sibling tools like list_dataframes or copy_dataframe. However, it does not explicitly differentiate itself from other state-changing tools, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool: 'when working with multiple dataframes.' This gives clear usage context, but it does not mention alternatives or when not to use it. The phrase implies the tool is for switching among multiple loaded datasets, which is adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that only tree-based models are supported, and the example shows expected usage. But it omits behavioral details such as how save_path is used, what happens if the model is unsupported, whether the plot is displayed or saved, and any side effects. This is a significant gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose. It efficiently covers what the tool does, supported models, usage sequence, and includes a concrete example. Every sentence contributes value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description provides the essential purpose and example but leaves critical operational gaps unaddressed. Specifically, top_n and save_path semantics are undocumented, error conditions for unsupported models are not stated, and the description does not explain whether the plot is displayed or saved. While the output type is clear, the missing parameter details and behavioral caveats make the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only mentions model_name in the example ('model_name="random_forest_data_train"') but does not explain top_n or save_path, nor does it define model_name beyond the example. The description adds no meaningful parameter semantics beyond what the parameter names infer (e.g., top_n suggests a limit but not its role).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Bar plot of feature importance from a trained model.' It distinguishes from sibling tools like feature_importance (which likely computes values) and permutation_importance (different method) by clarifying it produces a plot and works with tree-based models. The example reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: 'Use after train_model to understand which features drive predictions.' It also scopes supported model types (random_forest, gradient_boosting, decision_tree). However, it doesn't mention alternatives like feature_importance or permutation_importance for numerical importance, so it stops short of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the supported methods and custom binning format but does not state whether the operation mutates data, handles missing values, or requires a specific dataframe context. Some transparency is provided via examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by method details and illustrative examples. Every sentence contributes to understanding, though the examples add length they are valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and moderate complexity. The description covers the core binning logic and methods well, but omits criteria for dataframe selection and output column naming. The presence of an output schema likely reduces the need to describe return values, so completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'bins' (integer vs list), 'method', and provides examples for 'column' and 'labels'. However, 'df_name' and 'new_column' are not explained, leaving gaps for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discretizes numeric columns into bins/categories, using a specific verb and resource. It does not explicitly contrast with sibling encoding tools, but the numeric binning purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for binning numeric columns) and demonstrates its methods with examples. It lacks explicit guidance on when not to use it versus alternatives like label encoding or normalization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds value by explaining AUC semantics and provides a usage example, but it does not disclose side effects like saving to save_path, what the function returns, or behavior if the model or dataframe is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a brief explanation of AUC and an example. The AUC interpretation is useful but might be considered extra, though it does not detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the purpose, an example, and AUC context, but lacks explanations of all parameters and output/return behavior. With no output schema and no annotations, the description should cover more ground, especially for save_path and target_column.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It only provides an example for model_name and test_df_name, leaving save_path and target_column unexplained. This is insufficient for a 4-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool plots an ROC curve with AUC for binary classification models, using the specific verb 'Plots' and a named resource. It differentiates from other plot tools by its focus on ROC/AUC, though it does not explicitly contrast with siblings like plot_precision_recall_curve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for binary classification models and explains the AUC interpretation, providing clear context for when to use it. However, it does not explicitly state exclusions or mention alternatives, such as using precision-recall curves for imbalanced data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 conveys a read-only operation by saying 'Get' and 'Check' and compares output to pandas df.info(). However, it does not explain what happens when df_name is empty or invalid, how the target dataframe is selected, or whether it can raise errors. The behavior is adequately implied for a simple info tool but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. However, the sentence 'Check column types and non-null counts' is largely redundant with the first sentence, so there is minor waste. Still, the overall length is appropriate and the key information is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and an output schema, so the description does not need to explain return values. It covers purpose and a usage trigger. Yet the df_name parameter is left unexplained, and the 'for the dataframe' phrasing is ambiguous, so the description is not fully complete for an agent to use it correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, df_name, and the schema description coverage is 0%. The description never mentions df_name, how it is used, what values it accepts, or what happens when it is left as the default empty string. The phrase 'for the dataframe' is too vague to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and resource ('the dataframe'), listing exact outputs: column dtypes, non-null counts, and memory usage. It also adds the 'Similar to pandas df.info() output' analogy and a concrete use case ('verify names'), which clearly differentiates it from siblings like get_statistics or get_head.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear, explicit trigger: 'Run when a tool reports 'column not found' to verify names.' It also describes the purpose (checking column types and non-null counts). It does not mention when not to use it or name alternatives, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that results are sorted by count descending and mentions the exploratory purpose. Missing are explicit statements about non-destructiveness, handling of missing values, or return format (though an output schema exists). The behavioral information is minimal, likely insufficient for an agent to fully anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, front-loading the core behavior. Every sentence adds value: the purpose, the use case, and a concrete invocation. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple exploration tool, the description covers the main purpose and usage. However, it omits mention of which dataframe the tool operates on (df_name) and does not address how it relates to get_value_counts, which is a closely related sibling. These gaps reduce completeness in the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'column' conceptually and demonstrates 'top_n' in the example, but 'df_name' is completely unexplained. The example clarifies the use of column and top_n, but the third parameter remains ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists unique values with frequencies for a column, sorted by count descending. It is specific about the verb and resource. However, it does not differentiate itself from the sibling tool get_value_counts, which likely serves the same purpose, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use it ('Understand categorical columns before encoding') and suggests a downstream action ('Reveals rare categories that may need grouping'). However, it does not explicitly mention any alternative tools or exclusions, and the overlap with get_value_counts is not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not disclose behavioral details such as whether the plot is displayed or saved (save_path parameter), how missing values are handled, or any side effects. The example shows usage but does not describe output or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and includes a concrete example. Every sentence contributes value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, no output schema, and many sibling plot tools, the description is too sparse. It covers the main purpose and one example but omits important usage details like group limiting (top_n_groups) and file saving, making it incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The example clarifies the 'column' and 'by' parameters, but 'df_name', 'save_path', and 'top_n_groups' remain unexplained. This is a significant gap for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Overlay KDE distributions') on a specific resource ('numeric column') with a grouping dimension. It distinguishes itself from sibling plot tools by explicitly positioning itself as better than separate histograms for comparing distribution shapes across categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear comparative guideline ('Better than separate histograms for comparing distribution shapes across categories') that helps decide when to use this tool. It does not explicitly mention alternative tools like violin or box plots, but it gives enough context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals that multiple y columns can be overlaid and that sorting matters, but it does not mention expected input format, whether it renders inline or saves, or any side effects. For a plotting tool, this is an acceptable but incomplete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably sized but includes redundancy: 'For time-series data and trends' and 'Supports multiple y columns overlaid' are each repeated. While examples are useful, the repetition adds no value and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, and key parameters, but lacks information about df_name and save_path, and does not explain what the tool returns (e.g., a plot object, file, or display). Given no output schema and no annotations, this leaves moderate gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The examples clarify the semantics of x, y, and hue (e.g., plot_line(x='date', y=['Revenue','Cost'], hue='Category')). However, df_name and save_path are not explained, leaving their purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a line plot and emphasizes its use for time-series and trends, distinguishing it from other plot types (e.g., scatter, bar). The examples demonstrate the intended output, though the opening 'Line plot' is somewhat redundant with the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool ('For time-series data and trends') and provides a key prerequisite ('Sort data by x-axis column first'). It does not explicitly list alternatives or when-not-to-use, but the context is clear enough for an agent to select this over sibling plot tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains how to interpret the Q-Q plot ('Points on the diagonal = normal. Deviations show skewness or heavy tails'), which is useful. However, it does not disclose what the tool actually outputs (e.g., renders a plot, returns an object, saves to a path), nor does it mention side effects or requirements like numeric data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It opens with the purpose, then explains interpretation, gives a usage tip, and ends with a concrete example. Every sentence adds value and none are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple plotting tool, the description covers the main purpose and interpretation but is incomplete regarding parameters and return behavior. Since there is no output schema, the description should explain whether the plot is displayed, saved, or returned as an object. The missing df_name and save_path semantics also reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only minimally addresses the 'column' parameter through an example (plot_qq(column="Revenue")), and completely ignores 'df_name' and 'save_path'. Users have no idea what these parameters do, making the description insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Q-Q plot to visually assess if a column follows a normal distribution.' It identifies the resource (a column) and the specific goal (normality assessment). It also distinguishes itself from the statistical test normality_test, but does not use an explicit verb like 'creates' or 'displays', which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use alongside normality_test for visual confirmation.' This tells the user when to use it (in conjunction with a normality test for visual backup). It does not mention alternatives or when not to use it, but the pairing advice is clear and valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose whether the operation mutates the original dataframe or returns a new one, nor how invalid mapping keys are handled. For a transformation tool, this is a significant behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, usage guidance, and a code example. It is front-loaded, has no fluff, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers purpose and provides an example, making it minimally viable. However, missing mutation semantics and df_name behavior leave notable gaps. The presence of an output schema reduces the need to describe return values, but behavioral details are still absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. The core 'mapping' parameter is clearly described via the old->new definition and an example. However, the optional 'df_name' parameter is completely unexplained, leaving ambiguity about the target dataframe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Rename columns using an old->new mapping' with a specific verb and resource, clearly identifying the operation on column names. It is distinct from sibling data-transformation tools, but it does not explicitly name alternatives, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Standardize column names early in the pipeline' and explains the benefit of preventing reference errors, providing clear context for when to use the tool. It does not mention exclusions or alternative tools, but the usage guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 a behavioral trait: 'Sorts by index automatically.' However, it does not explain whether the operation mutates the dataframe in-place, returns a new dataframe, or how the target dataframe is identified (e.g., via df_name). Missing these side-effect details leaves ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are redundant: 'Set a datetime column as the DataFrame index. Set datetime column as DataFrame index.' This wastes space. The rest (resampling requirement, auto-sort, example) is informative, but the redundancy prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 an output schema that is not described, the description should provide enough context to invoke it correctly. It fails to explain the role of df_name, the return value, or side effects on the dataframe. This is a significant gap for a tool that modifies dataframe state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 clarifies the 'column' parameter by specifying it must be a datetime column and provides an example, but it says nothing about 'df_name' at all. This leaves one of two parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Set a datetime column as the DataFrame index.' It also adds context by mentioning that it sorts automatically and is required for time-series resampling, distinguishing it from sibling tools that perform other dataframe operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Required for time-series resampling.' It does not explicitly mention alternatives or when not to use it, but none of the sibling tools appear to serve this specific index-setting purpose, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the operation modifies the dataframe in place or returns a new one, whether it overwrites an existing column, or how the df_name parameter affects behavior. The word 'reset' implies overwriting but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences including an example, with no redundant information. The main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, reducing the need to describe return values. However, the missing df_name explanation and lack of behavioral details (e.g., in-place vs. return) leave gaps. For a mutation tool with no annotations, more context would be expected for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The example implies that start sets the starting value and column_name names the column, but df_name is never mentioned. This is insufficient for the 3-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Add or reset a numeric row index as a column.' It clearly differentiates from other column operations (e.g., create_column, rename_columns) by focusing on row indexing. The example further clarifies expected usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Useful after filtering to create unique IDs or reset row numbering.' This tells the agent when to use the tool, though it does not explicitly name alternatives or exclusion criteria, preventing a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that columns are dropped and gives an example. It does not disclose whether the operation is in-place or returns a new dataframe, what happens if a column doesn't exist, or any side effects. This is a significant gap for a mutation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: a clear action, a guiding note, and a concrete example. It is front-loaded and every sentence earns its place. No fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return values need not be explained. However, the description omits details about the 'df_name' parameter and the mutation behavior. The guidance is useful but not comprehensive. It is minimally viable for a simple tool, but the lack of side-effect disclosure and parameter completeness keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The example clarifies the 'columns' parameter (list of strings), but the 'df_name' parameter is not mentioned at all. The description adds some meaning for 'columns' via the example but fails to provide any semantics for the optional 'df_name' parameter, leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drop specified columns from the dataframe') and the resource (dataframe columns). It distinguishes itself from siblings like drop_duplicates and drop_missing by specifying columns. The additional guidance on what types of columns to remove (constants, IDs, leaked features) further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: to remove useless columns like constants, IDs, and leaked features. It also cautions to 'always understand a column before dropping it'. However, it does not explicitly mention alternatives or when-not-to-use scenarios, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of revealing behavior. It discloses the available methods (pearson, spearman, kendall) and that it returns a value and interpretation, which covers the core behavior. However, it does not mention whether it operates on the current dataframe, how missing values are handled, or any read-only guarantees, leaving some ambiguity about side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy: 'Compute pairwise correlation between two numeric columns' and 'Measure relationship between two numeric columns' say essentially the same thing. The example is useful, but the repetition adds unnecessary words without new information, making it slightly less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no schema descriptions and no annotations, the description is incomplete. It explains the core purpose, methods, and usage context, but omits the df_name parameter entirely, which is needed for full invocation control. The presence of an output schema helps with return values, but the parameter gap and unclear dataframe scope make this insufficient for confident tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It clarifies col_a and col_b as numeric column names and lists valid method options, and the example demonstrates the parameter syntax. However, the df_name parameter is completely ignored, leaving it undocumented, which is a significant gap given the absence of any schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes pairwise correlation between two numeric columns, lists the supported methods, and explains it returns a value and interpretation. It also distinguishes itself from the related plot_correlation_matrix tool by positioning itself for targeted follow-up investigation, making the purpose explicit and differentiating it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage scenario: 'Use for targeted investigation after plot_correlation_matrix reveals interesting pairs.' This tells the agent when to apply this tool versus the broader visualization alternative. It does not explicitly mention other alternatives like correlation_filter, but the provided guidance is enough for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the heatmap's color mapping and diagnostic intent. However, it omits behavior around the optional df_name and save_path parameters, and does not state whether the plot is displayed or saved to a file, leaving operational ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with each sentence serving a purpose: purpose, color legend, usage condition, interpretation, and an example. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for selecting the tool and understanding its output, especially with the zero-argument example. However, without an output schema or annotations, the lack of parameter behavior and display/save details leaves gaps for full invocation confidence in non-default scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (df_name, save_path) have no schema description, and the description adds no parameter semantics. The example plot_missing_values() implies zero-arg invocation, but it does not explain that df_name references a loaded dataframe or that save_path controls an output file. This fails to compensate for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Heatmap showing missing value patterns across all columns.' It also provides the color legend (white = present, colored = missing), which clearly distinguishes this tool from sibling plotting tools like plot_heatmap by focusing on missingness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use when quality_report shows significant missingness.' It also explains the interpretive value of the heatmap for detecting random vs. systematic missingness. It does not mention alternatives/exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'Sort the dataframe' without disclosing whether the sorting happens in-place, returns a new dataframe, or has any side effects on the original data. The df_name parameter suggests a data frame context, but the effect is ambiguous. This is a significant behavioral gap for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, with no unnecessary verbiage. The main purpose is front-loaded, and the example is practical. Every sentence earns its place, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple sorting tool, the description is mostly adequate. It tells when to use it and gives an example. However, it omits important context about the df_name parameter and whether the operation mutates or returns a new dataframe. Since there is an output schema (per context signals), return values are not required in the description, but the missing parameter semantics and behavioral transparency leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the tool description must explain the parameters. It only covers 'columns' (via 'one or more columns') and gives an example with 'ascending'. It does not explain 'df_name' (which is likely needed to specify the dataframe) or clarify the default of 'ascending=true'. The description adds some value but fails to fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Sort the dataframe by one or more columns.' It names the resource and provides a concrete example with 'sort_values(columns=["Revenue"], ascending=False)'. This is a specific verb+resource and is distinct from sibling tools like filter_rows or drop_duplicates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Sort before visual inspection or time-series analysis. Useful before plot_line.' This tells the agent when to use the tool, but it does not explicitly mention when not to use it or name alternatives. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the test purpose and does not disclose behavioral aspects such as required data types (categorical), handling of missing values, underlying assumptions (e.g., expected counts), output structure, or potential errors. It adds little beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, highly concise and front-loaded. It contains no filler and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, but the description omits important statistical context (e.g., assumptions of the chi-square test, handling of small expected counts) and the role of df_name. It is sufficient for a simple invocation but incomplete for a robust statistical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The example chi_square_test(col_a="CargoType", col_b="ProductCode") clarifies that col_a and col_b are column names. However, df_name is not mentioned or explained, and there is no mention that columns should be categorical, which is essential. Partial credit is given for the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool performs a Chi-square test of independence between two categorical columns and tests for association or independence. This clearly distinguishes it from other statistical tests in the sibling list (e.g., ttest_independent, anova_test) by specifying categorical columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: when you want to test association between two categorical variables. However, it does not explicitly mention alternatives or when not to use it (e.g., for continuous variables), and does not note prerequisites like needing a current dataframe. It implies usage but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It lacks critical details such as whether the operation mutates the DataFrame in place or returns a new one, how errors are handled for invalid conversions, and any side effects on other columns or the current dataframe context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, followed by supported types, a use-case tip, and a concrete example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and an output schema exists, so return values may be covered elsewhere. However, the description lacks behavioral details (e.g., in-place vs. return, error handling) and does not clarify the df_name parameter, leaving some contextual gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 list valid dtype values and gives an example with columns and dtype, but it omits the df_name parameter entirely and does not explain the expected format for columns beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Convert column types') and lists supported dtypes. It also distinguishes itself from siblings by framing the operation as type conversion rather than selection or encoding, and provides a concrete example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit timing guidance ('Do this BEFORE statistical analysis or encoding') and identifies a common use case (fixing numeric stored as string). However, it does not mention when not to use the tool or point to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It reveals the output format ('formatted table') and implies a non-mutating operation by using 'Return.' It does not explain the effect of the df_name parameter (e.g., whether it operates on the current dataframe or a named one) or any potential side effects, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise and front-loaded with the primary purpose. The second sentence 'Check the last rows.' is somewhat redundant, but the example adds clarity without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers purpose, usage context, and an example. However, it omits details about df_name, which is a parameter with no schema description, and does not clarify what 'formatted table' entails beyond the output schema hint. This leaves some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'n' parameter through the example 'get_tail(n=10)' and the phrase 'last N rows,' but the df_name parameter is not mentioned at all. This leaves half the parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the last N rows of the dataframe as a formatted table.' It uses a specific verb ('return'), specifies the resource ('last N rows of the dataframe'), and describes the output format. It also differentiates from siblings like get_head by focusing on the last rows and mentions time-series utility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Useful for time-series to see the most recent data.' This tells the agent when to consider this tool. However, it does not explicitly mention alternatives or when-not-to-use, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It discloses sort order, percentage inclusion, cumulative percentages, and top_n limiting, but it does not mention the return format, default dataframe behavior, or how missing values are handled. This is moderate transparency, not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus an example, stays on-topic, and front-loads the core behavior. Some redundancy exists ('Detailed frequency analysis' restates the first sentence), but the example and comparison add value without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward and an output schema exists, so the description does not need to explain return fields. However, the df_name parameter is not explained, and the relationship to the current dataframe context is absent. This leaves a nontrivial gap, though the core function is otherwise described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 clarifies column and top_n via the example and the 'Shows top_n values' phrase, but df_name is completely omitted, leaving an important parameter (the dataframe identifier) unexplained. This partial coverage is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as one that computes value counts with percentages and cumulative percentages, sorted descending. It explicitly contrasts with plot_bar ('More detailed than plot_bar'), which differentiates it from a key sibling and makes its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's context is clear: it is for detailed frequency analysis rather than a quick plot. It names plot_bar as an alternative and claims to be more detailed, but it does not enumerate other contexts where a different tool would be preferred, so it misses explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a key behavior: 'Stores result as a new dataframe', and implies summary generation. However, it doesn't elaborate on side effects, handling of missing data, or how the original dataframe is affected. Some behavioral detail is present but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded, and includes a concrete example. Every sentence adds value; the example is particularly useful for parameter understanding without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and zero schema documentation, the description is adequate but incomplete. It provides a use case and example, and the output schema covers return values, but it does not explain all parameters (df_name, result_name) or clarify how the tool integrates with the dataflow context. Reasonable for an agent but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The example demonstrates usage of index, columns, values, and agg_func, but df_name and result_name are not explained. The example adds partial meaning, yet fails to fully cover all six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a pivot table' and 'Create summary tables' with a specific example. It distinguishes from siblings by mentioning 'reshaping data from long to wide format', which contrasts with melt_dataframe, though it doesn't name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Use for reporting or reshaping data from long to wide format.' This tells when to apply the tool, but doesn't explicitly state when not to use it or mention alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 transparency. It discloses the core output (a heatmap with counts) and the recommended timing (after evaluate_model), but it does not mention side effects like saving to a file via save_path, what the function returns, or any required input conditions. The context is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise sentences: purpose, content, and an example. It is front-loaded with the most important information and contains no redundant or irrelevant text. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 4 parameters, no annotations, and no output schema, the description is not contextually complete. It provides a clear purpose and a usage hint but omits explanation of all parameters, return behavior, and edge cases. The bare minimum for a usable tool description is met, but significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides an example using model_name and test_df_name, but it does not explain save_path or target_column, nor does it clarify the implications of leaving all parameters optional. This leaves the user guessing about the full parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a confusion matrix heatmap showing true vs predicted labels with counts. It distinguishes itself from sibling plotting tools by specifying it's for classification models and uses the term 'confusion matrix', which is unique among the listed plot tools. The example invocation further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using the tool after evaluate_model for deeper diagnosis, providing a clear workflow context. It doesn't explicitly mention alternatives or when not to use it, but the specificity to confusion matrices implies it is the go-to for that particular diagnostic, which suffices for a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the core output behavior (cumulative distribution) but does not disclose prerequisites (e.g., numeric column), potential side effects (e.g., displaying a figure), or details about df_name and save_path behavior. This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it defines the plot type, explains its function, states a use case, and provides an example. Every sentence earns its place, and it is appropriately sized for a simple plotting tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for operational use: it does not clarify how df_name selects the dataframe, what save_path does, or what the function returns/displays. Given the lack of schema parameter descriptions, this leaves important gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The example illustrates the column parameter, but df_name and save_path are not explained. Since schema description coverage is 0%, the description fails to compensate for these undocumented parameters, leaving their semantics mostly to inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a CDF plot and explains what it shows ('percentage of data falls below each value'). This distinguishes it from other plot types like histogram or scatter, and the example reinforces the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a specific use case ('useful for understanding thresholds'), giving agents context for when to choose this tool. However, it does not mention alternatives or exclusion criteria, which would be helpful in a toolset with many plotting siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It explains that the tool computes and plots scores, but omits details such as whether the plot is displayed, saved (despite a save_path parameter), or what happens if the model is not trained. The diagnostic purpose is clear, but side effects and prerequisites are not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, opening with the core purpose and followed by diagnostic utility and a pragmatic example. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is incomplete. It does not address how the plot is output/displayed, the meaning of n_splits and save_path, or any prerequisites. The example helps but is not sufficient for full autonomous usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains model_name and train_df_name via the example, leaving n_splits, save_path, and target_column unexplained. This is insufficient for a 5-parameter tool with no schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: plotting learning curves showing training and validation scores vs training set size. It also provides diagnostic context (overfitting and underfitting), and the example call differentiates it from other plot tools that focus on data distributions or correlations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: to diagnose overfitting and underfitting by comparing training/validation scores. This gives clear context for usage, though it does not mention alternatives or when not to use it. The example also demonstrates a typical invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that computation is expensive and that the plot is limited to 6 columns, which is useful. However, it does not explain behavior for exceeding 6 columns, how df_name or save_path affect execution, or what the function returns (e.g., a plot object or file).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states what it does, followed by usage tips and an example. Every sentence adds value and it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema exists and annotations are absent, the description omits key contextual details such as how to specify the dataframe (df_name), how saving works (save_path), and what happens when more than 6 columns are passed. These are significant gaps for a plotting tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 provides an example using columns and hue, giving some meaning to those parameters. But it does not explain df_name or save_path at all, leaving half the parameters undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Seaborn pairplot for up to 6 columns, showing distributions on the diagonal and scatter plots off-diagonal. This specific verb+resource pairing and visual detail distinguish it from other plotting tools like plot_scatter or plot_histogram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use after feature_importance to focus on top features' and advises limiting to 6 columns for readability. It also warns that computation is expensive. However, it does not explicitly state when not to use it or mention alternatives beyond the implicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions showing the trade-off between precision and recall but does not disclose whether the plot is displayed, saved (despite a save_path parameter), or any side effects, permissions, or return behavior. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose stated first, followed by a comparative note, and then an example. All three sentences serve a distinct purpose with no repetitive or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no annotations, and no output schema, the description is too sparse. It does not explain important inputs like save_path or target_column, nor does it clarify what the tool returns or how the plot is delivered. While the example helps, it is insufficient for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has four parameters with zero description coverage. The example hints at the usage of model_name and test_df_name (shows them as string arguments), but it does not explain their meaning or provide any guidance for the remaining save_path and target_column parameters. The description adds only minimal semantic value through the example, failing to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: plotting a Precision-Recall curve for binary classification models. It even differentiates from the sibling tool plot_roc_curve by noting it's 'Better than ROC for imbalanced datasets', effectively distinguishing it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool: 'Better than ROC for imbalanced datasets' directly tells the agent to prefer this tool over ROC in that scenario. This is a clear comparative usage instruction, similar to the high-calibration example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the plot is displayed, saved to the save_path, or if there are any side effects. It also doesn't address handling of non-numeric inputs beyond stating that columns should be numeric. This is a minimal disclosure of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and includes a helpful example without fluff. Every sentence earns its place, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core use case adequately, but with no annotations or output schema, and 5 parameters, it lacks details on how df_name and save_path function, and what the tool returns (e.g., a plot object or file). For a plotting tool, this leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for x, y, and hue (numeric and categorical roles) and includes a concrete example. However, it leaves df_name and save_path unexplained, and schema coverage is 0%. Since more than half the parameters are undocumented, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a scatter plot between two numeric columns, which is a specific verb+resource. It distinguishes from sibling plotting tools by focusing on scatter plots and optional hue grouping. The example further clarifies usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use to explore relationships between two numeric variables, and hue for subgroup patterns. However, it does not explicitly mention alternatives or when not to use it, though the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains the visual output nature but does not mention side effects, whether it displays or saves the plot, or any requirements like a current dataframe. This is a significant gap for a plotting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences plus a relevant example. No filler, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema or annotations. The description does not explain return values, output format, or effects like file saving. It is too minimal to fully inform an agent how to use the tool correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only partially compensates by showing an example with 'column' and 'by'. The parameters 'df_name' and 'save_path' are never mentioned, leaving their meaning unclear. The agent must infer them from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Violin plot: combines box plot with KDE to show full distribution shape.' It uses a specific verb and resource, and distinguishes itself from siblings like plot_box by noting it is 'Better than boxplot for skewed or multimodal distributions.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by comparing with alternatives ('Better than boxplot for skewed or multimodal distributions') and gives a concrete example. This tells the agent when to choose this tool over plot_box and how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not explicitly state whether the operation is read-only or modifies the dataframe, nor does it mention the role of random_state in reproducibility or any sampling details (e.g., with/without replacement). This lack of explicit safety and randomness behavior is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an example), front-loaded with the primary action, and contains no fluff. The example is helpful and directly reinforces the main parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema coverage and lack of annotations, the description is incomplete for effective use. It fails to explain the df_name parameter (which dataframe to sample) and random_state, making it difficult for an agent to correctly invoke the tool beyond the n parameter. The existence of an output schema helps but does not compensate for missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explaining all parameters. It only addresses 'n' indirectly via the example (sample_data(n=5)), and entirely omits 'df_name' and 'random_state'. This leaves the agent without necessary semantic information for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Return a random sample of N rows.' It uses a specific verb ('return') and resource ('random sample'), and distinguishes itself from siblings by explicitly mentioning 'head/tail are not representative.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when head/tail are not representative,' and even names the alternatives (head/tail). This provides clear guidance on when this tool is preferable, fulfilling the criteria for explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the model is stored for later predict/evaluate and that ALL numeric columns are used as features. However, it does not mention potential side effects like overwriting existing models, handling of missing values, or data requirements beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with the core purpose, lists options, gives strategic guidance, and ends with a concrete example. Every sentence adds value, though the list of model types could be considered somewhat lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema, the description covers the core purpose and usage strategy but misses key details about parameters and data expectations. It is adequate for an initial understanding but incomplete for safe and effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage, so the description must compensate. It explains the values for 'model_type' and gives an example using 'target_column', but completely neglects 'model_name', 'hyperparams', and 'train_df_name'. This leaves three parameters semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the specific verb 'Train' and resource 'a model', followed by a clear list of model types. It distinguishes itself from sibling tools like predict and evaluate_model by explicitly stating that the trained model is stored for later use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: start with a simple baseline model and only move to complex models if the baseline is insufficient. This is clear when-to-use advice, though it does not explicitly mention alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It adds useful context about using pandas eval expressions and the epsilon tip, but it does not specify whether an existing column is overwritten, whether the operation modifies the DataFrame in-place, or how the df_name parameter affects which DataFrame is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with a clear verb and object. The use-case sentence and epsilon guideline earn their place, and the two examples are helpful. It could be slightly more compact by merging the examples, but they add concrete value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (custom eval expressions), and the description covers the core behavior, use cases, and a key tip. However, it omits details about the df_name parameter and potential edge cases like overwriting existing columns. An output schema exists, so return values are likely covered, but the description still leaves some operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for the three parameters (coverage 0%), so the description must compensate. The examples clarify new_column and expression (e.g., expression='Revenue / (ChargeableWeight + 1e-5)'), but the df_name parameter, despite having a default, is never mentioned or explained, leaving its semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb+resource: 'Create a new column using a pandas eval expression.' It also provides two concrete examples that illustrate the intended use for ratios and interactions, distinguishing it from other feature-engineering siblings like polynomial_features or log_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for when to use it: 'For domain-relevant feature engineering: ratios, differences, interactions.' It also provides a practical guideline on adding epsilon to avoid division by zero. However, it does not explicitly mention when not to use it or name alternative tools, falling 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what is plotted and the concept of the elbow point, but it does not disclose behaviors such as how df_name is used, what save_path does, or what the function returns. With no annotations provided, the description carries the full burden and falls short on these operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three focused sentences and a helpful example. Every sentence adds value, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core purpose is clear, the description omits essential context for parameters like df_name and save_path, and does not specify return behavior or data requirements. For a 5-parameter tool with no annotations or output schema, this is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description must explain all parameters. It only mentions columns and max_k in the example, leaving df_name, save_path, and random_state completely unexplained. This is a significant gap for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating an elbow plot to find the optimal number of clusters for K-Means. It specifies the resource (inertia vs number of clusters) and distinguishes this from sibling clustering tools like kmeans_cluster or silhouette_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies when to use the tool (before K-Means to determine K) and provides an example. However, it does not explicitly name alternatives or state when not to use it, so it lacks the explicit exclusion criteria seen in higher-scoring guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does mention 'Original column is preserved' and the naming convention, which is useful. However, it does not clarify what happens when 'parts' is null (the schema default), nor does it address invalid datetime formats or whether the operation modifies the dataframe in place. These gaps leave some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, available parts, usage guidance, and an example. It is front-loaded with the core action and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 3 parameters and an output schema, but the description lacks details about df_name and default parts behavior. The use case and example are helpful, but an agent needs more information to invoke the tool correctly in all scenarios, especially since there are no annotations and schema descriptions are empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It adds meaning for 'column' via the example and naming pattern, and for 'parts' by enumerating possible string values. However, it completely omits any explanation of the 'df_name' parameter, and the default behavior of 'parts' (null) is not explained. This fails to fully compensate for the lacking schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Extract datetime components as new columns' with a concrete naming pattern and lists the exact components (year, month, day, etc.). This distinguishes it from sibling datetime tools like datetime_diff, datetime_filter, and set_datetime_index, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: 'Use early in feature engineering when datetime columns exist' and even highlights which parts are 'often highly predictive.' It does not explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description must disclose behavioral traits. It states the output (ranked list) and the available methods, and implies a read-only computation. However, it does not explicitly confirm that the dataframe is not modified, what inputs are required (e.g., preprocessed numeric data), or how missing values are handled. This leaves a moderate gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core verb and resource, then lists methods, output, usage guidance, and an example. It is slightly verbose but each sentence contributes useful information. No redundant fluff, though it could be tightened by removing the vague 'Ranks features by predictive power' sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so the return structure is known. Given the tool's moderate complexity and the lack of annotations, the description covers the main purpose, usage timing, methods, and provides an example. However, it does not explain the df_name parameter, potential prerequisites (e.g., encoded data), or possible limitations (e.g., only works for classification vs regression). Overall, it is mostly complete but leaves a few gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, so the description must compensate. It explains the 'method' options, shows usage of 'target_column' and 'top_n' in an example, but omits 'df_name'. This partial coverage adds meaning for three of four parameters, but the missing df_name parameter remains unexplained, making the parameter semantics adequate but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes feature importance using tree-based models or mutual information and returns a ranked list of features with scores. It uses a specific verb ('Compute') and resource ('feature importance'), and naturally distinguishes itself from sibling tools like correlation_filter, drop_low_importance, and plot_feature_importance_model by focusing on ranking predictive power.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit timing guidance: 'Run after all encoding and feature engineering.' It also explains the purpose ('Ranks features by predictive power. Helps focus modeling on most important features.'). While it does not explicitly state when not to use it or name alternatives, the context is clear enough for an agent to choose this over other feature-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden of behavioral disclosure. It explains what each strategy does and notes that columns=None fills all columns with nulls. However, it does not disclose whether the operation modifies the dataframe in place or returns a new one, nor does it mention any side effects or dependencies like the 'df_name' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the core purpose, lists strategies, provides parameter clarification, gives usage guidance, and includes a clarifying example. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While a separate output schema exists and return values need not be described, the omission of the 'df_name' parameter is a critical gap. Given there are 4 parameters and the description covers only two meaningfully, the tool lacks the contextual completeness needed for an agent to invoke it correctly, especially to identify which dataframe to mutate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, so the description must compensate. It explains 'columns' (None = all columns with nulls) and enumerates valid 'strategy' values, but it only indirectly implies the 'value' parameter ('value' (literal)) and completely omits 'df_name'. The example demonstrates usage of 'columns' and 'strategy', but not the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fill missing values' and enumerates the supported strategies ('value', 'mean', 'median', 'mode', 'ffill', 'bfill'). This is specific and distinguishes it from the sibling tool 'drop_missing', which removes missing values instead of filling them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on strategy selection: 'median' for skewed numeric, 'mean' for normal, 'mode' for categorical, and 'ffill'/'bfill' for time-series. However, it does not mention when to prefer filling over dropping missing values (e.g., versus 'drop_missing'), so there is no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the core behavior (grouping and aggregating) and lists supported functions, which gives a basic understanding. However, it does not disclose edge-case behavior (e.g., handling of missing values, non-numeric columns, multiple group-by columns) or what the exact return structure is, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a clear definition, supported functions, usage context, and a concrete example. Every sentence adds value and the example is highly illustrative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values need not be described) and the tool is relatively simple, the description covers the purpose, use case, and example adequately. It is slightly incomplete regarding df_name and possible variations, but overall it is sufficiently complete for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The example clarifies group_by, agg_column, and agg_func semantics well, and the function list adds meaning to agg_func. However, df_name is not mentioned at all, and there is no explanation of how the target dataframe is selected, which is a notable gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a 'GroupBy aggregation' with a specific list of functions (mean, sum, count, min, max, median, std) and includes a concrete example. It is specific about the verb and resource, but it does not explicitly distinguish this from the closely related sibling 'group_aggregate_multi' or other aggregation tools like 'describe_by_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use-case context: 'For segmented analysis: understanding how metrics differ across groups' and gives a business example. However, it does not mention when not to use this tool or explicitly point to alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behaviors: features are auto-standardized and the result is stored as a new column. However, it does not mention potential side effects like overwriting an existing column, how missing values or non-numeric columns are handled, or whether the operation modifies the dataframe in place. These omissions leave some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening statement, followed by key details, use cases, and a concrete example. No redundant or filler language is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but with 5 parameters, no annotations, and an output schema that is not visible, the description should cover more. It gives purpose, usage, and an example, but lacks detail on three important parameters and edge-case behavior. The output schema existence reduces the need to explain return values, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'columns' (numeric columns) and 'n_clusters' (via example), but leaves 'df_name', 'random_state', and 'cluster_column' completely undiscussed. These parameters are not self-evident from their names alone, especially 'cluster_column' and 'df_name'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'K-Means clustering. Assigns each row to one of n_clusters groups based on numeric columns.' This uses a specific verb ('assigns') and resource (rows to clusters) and includes an example. It distinguishes from sibling tools like dbscan_cluster by explicitly naming the K-Means algorithm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use contexts: 'Use for customer segmentation, anomaly grouping, or discovering natural data groups.' However, it does not explicitly mention alternatives or exclusion criteria, such as when DBSCAN might be more appropriate, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains the transformation and parameter roles, but does not disclose whether the operation mutates the dataframe or returns a new one, nor any side effects. Adequate but incomplete for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, well-structured sentences: definition, parameter roles, and a concrete example. No fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core transformation, usage guidance, and an example, but lacks details on df_name, var_name, value_name, and side effects. An output schema exists, so return values are likely covered, but the description itself is not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 id_vars and value_vars with definitions and an example, but leaves df_name, var_name, and value_name unexplained. This partial coverage leaves ambiguity for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Unpivot (wide to long format)' and explains what id_vars and value_vars do. It distinguishes itself from pivot_table by noting 'Reverse of pivot,' making it easy for an agent to identify when this tool is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when data is in wide format but tools expect long format.' Also mentions 'Reverse of pivot,' which implies the alternative (pivot_table). However, it doesn't explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavior disclosure. It discloses that the tool produces both a residuals vs predicted values plot and a histogram of residuals, which is useful. However, it does not describe prerequisites (e.g., a trained model and test dataframe), side effects, or error handling. The example hints at required inputs but does not fully disclose behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: clear purpose, interpretation guidance, and a concrete example. All sentences add value, and the structure is front-loaded with the primary purpose, making it concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and no output schema, the description covers the core purpose and usage but leaves gaps in parameter semantics and expected inputs. The example provides a basic invocation pattern, but an agent needs more detail to understand save_path and target_column or to handle optional parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The example specifies model_name and test_df_name, but save_path and target_column are never explained. No format, meaning, or relationships are provided for the parameters beyond the example, leaving half of them undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a residuals vs predicted values plot for regression models, a specific verb+resource. It distinguishes itself from sibling plotting tools by focusing on residual diagnostics and includes interpretation guidance, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to diagnose model quality' and explains how to interpret the plot (random scatter = good, patterns = systematic error), providing a clear when-to-use context for regression model diagnosis. It does not explicitly mention alternatives or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the useful 'without row index' behavior, but omits side effects like overwriting existing files, directory creation, or how the dataframe is selected (via df_name). These gaps leave transparency moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: the first states purpose, the second provides usage context. No redundancy or filler, appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter export tool with an output schema, the description covers purpose and usage context well. However, the missing parameter semantics and overwrite behavior make it merely adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It implies file_path as the destination but fails to explain df_name and its default. This is a significant gap for a tool with only two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save a dataframe to a CSV file' with the qualifier 'without row index', specifying the action, resource, and a key behavioral detail. This distinguishes it from load_csv and other save tools like save_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use at the end of a pipeline to export cleaned/processed data.' While it doesn't name alternative tools, this is clear guidance for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 operations are applied in order and explains the 'replace' operation's dependency on replace_old and replace_new. However, it does not mention whether the operation mutates the dataframe in place, returns a new object, or what happens when 'operations' is null. These are meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence overview, a detail about 'replace', a usage rule, and an example. Every sentence adds value and there is no redundant phrasing. The example is especially useful for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and an output schema, the description covers the core operation, key parameter semantics, and pipeline context. It leaves out df_name and default behavior nuances, but for a string-cleaning utility it is largely self-contained. The presence of an output schema also means return-value details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no property descriptions (0% coverage), so the description must compensate. It explains 'column', 'operations' (with the list of allowed values), and 'replace_old'/'replace_new'. It omits 'df_name', which remains unclear. The example helps but does not fully cover the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Clean a string column', and enumerates the operations it supports ('strip', 'lower', 'upper', 'title', 'replace'). It also distinguishes itself by noting it should be run 'BEFORE any encoding', which separates it from encoding-focused sibling tools. However, it does not explicitly name an alternative tool for contrast, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Run on text columns BEFORE any encoding' and explains why ('Inconsistent casing or whitespace creates spurious categories'). This gives the agent a concrete trigger condition. It does not mention exclusions or alternative tools, but the context is sufficiently unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It discloses the return values (mean and std) and the overfitting detection behavior, but it omits details about side effects, prerequisites, or how the output is structured. The example helps but does not cover all behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the core function, then states the output, gives an advantage, and provides a concrete example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and an output schema, but the description leaves df_name and hyperparams undefined, making invocation potentially ambiguous. While the core purpose and benefits are covered, the lack of parameter details and edge-case behavior reduces completeness relative to the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, and the description compensates partially by showing an example with target_column, model_type, and n_folds. However, it does not explain df_name or hyperparams, leaving their meaning unclear. Given the low schema coverage, more parameter clarification would be expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'K-fold cross-validation' and returns mean and std of scores, making its purpose explicit. It also distinguishes itself from sibling tools by saying it is 'More reliable than a single train/test split', which differentiates it from train_test_split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, noting it is more reliable than a single split and that it detects overfitting when train scores exceed test scores. It does not explicitly name alternatives or state when not to use it, but the guidance is sufficient for selecting this tool over simpler validation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds some behavioral context by calling it a 'Quick dimension check' and implying a read-only verification step, but it does not disclose potential error conditions, side effects, or whether it returns a value or prints to console. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first stating the core purpose and the second giving usage context. Every word earns its place, and the most critical information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema present, the description covers the core functionality and a key usage scenario. However, it lacks any guidance on the df_name parameter, which is a minor but notable omission. Overall, it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention the df_name parameter at all. The parameter's title 'Df Name' on the schema provides only minimal hint of its meaning. Since the description fails to compensate for the low schema coverage, this dimension is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the number of rows and columns in the dataframe.' This is a specific verb+resource pairing that distinguishes get_shape from sibling tools like get_head, get_tail, and get_statistics, which focus on different aspects of the dataframe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: 'Always run after filtering or dropping to verify not too many rows lost.' This gives actionable guidance, though it does not mention when not to use it or suggest alternatives, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It adds helpful context: the tool operates 'in one call', supports a defined set of aggregation functions (mean, sum, count, min, max, median, std), and provides a concrete example. However, it does not explain side effects (e.g., whether the original dataframe is modified or a new one returned), default behavior for df_name, memory/performance characteristics beyond a vague 'efficient', or how missing values are handled. This is a moderate disclosure but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded. The first sentence gives the purpose, the second explains when to use it, the third lists available functions, and the fourth provides a concrete example. Every sentence adds value, with no redundancy or filler. The example is compact and directly clarifies the two complex parameters, making the description efficient despite the additional lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested aggregations object and an output schema, the description provides a useful example and function list, covering the most complex aspects. However, it omits any reference to df_name semantics, which is a required context for selecting the target dataframe, and does not mention any prerequisites (e.g., columns must exist, numeric types needed for certain functions). The output schema covers return values, but the operational context is not fully complete for an agent without prior assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The example successfully illustrates the structure and semantics of group_by (list of column names) and aggregations (dict mapping columns to lists of function names), and it implicitly shows that df_name can be omitted via default. However, df_name is never explicitly explained, and there is no systematic description of parameter semantics. The example is helpful but incomplete, especially for an agent that might not infer the role of df_name from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'GroupBy with multiple columns and multiple aggregation functions in one call.' This identifies the operation (group by) and key differentiating features (multiple columns and functions), and it distinguishes itself from the sibling tool group_aggregate by explicitly calling out efficiency gains. The function list and example reinforce what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: when multiple columns and multiple aggregations are needed, and explicitly states it is more efficient than calling group_aggregate repeatedly, naming that as an alternative. However, it does not state when not to use it (e.g., for a single aggregation) or mention other alternatives like crosstab or describe_by_group, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the non-parametric nature, the comparison of distributions, and the strict requirement of two groups. However, it does not detail the output structure or error conditions. Since an output schema exists, the return type is covered, but the description omits any caveats like independence assumptions or handling of missing values, making the transparency adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and each sentence contributes: the core definition, the non-parametric/sample-size constraint, when to use it, and a concrete example. No redundant phrases, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the output schema, covers the essential aspects: purpose, usage, and a limiting condition. The main missing piece is the df_name parameter semantics, but since it is optional and likely defaults to a current dataframe, this is a minor omission. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 clarifies 'column' as a numeric column and 'group_column' as the grouping via the example. However, 'df_name' is not explained at all, and the example omits it, leaving ambiguity about whether it is a dataframe name or something else. This is a significant gap given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a Mann-Whitney U test, explicitly describing it as a non-parametric alternative to the t-test that compares distributions of a numeric column across two groups. This distinguishes it from siblings like ttest_independent, anova_test, and normality_test. The example adds concrete usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use when normality_test indicates non-normal data' and includes a constraint: 'Requires exactly 2 groups.' This sets clear boundaries and implies alternatives for other cases, but does not explicitly name alternatives (e.g., Kruskal-Wallis for >2 groups), 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses normalize's effect on output (percentages vs. counts), but doesn't mention plot display/save behavior or consequences of parameters like save_path. Some behavioral context is present but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences including an example – concise, front-loaded with the core purpose, no unnecessary words. Each element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core plot type and normalize behavior, but with 6 parameters, no schema descriptions, and no annotations, it should explain top_n, df_name, and save_path. The example helps but doesn't make the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero description coverage, so description must compensate. It explains 'column' and 'by' via the example and 'normalize' explicitly, but leaves top_n, df_name, and save_path undocumented, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's a 'stacked bar chart showing composition of one categorical within another', which is a specific visual type distinct from siblings like plot_bar. Includes an explicit example demonstrating intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for composition analysis (one categorical within another) and explains normalize behavior. However, it doesn't explicitly name alternatives or state when not to use, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two important behaviors: 'Unmapped values stay as-is' and 'Values are auto-converted to match the column's type.' However, it does not state whether the operation mutates the dataframe in place or returns a new one, which is a notable gap for a transformation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it leads with the core action, then key behaviors, then use cases, then a concrete example. Every sentence adds value and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, key behaviors, use cases, and includes a clear example. With an output schema present, return values need not be explained. Minor gaps remain around df_name semantics and in-place vs. return behavior, but overall the description is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'column' and 'mapping' through prose and an example, and clarifies that values are auto-converted. However, the 'df_name' parameter is not mentioned at all, and the description only partially covers the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps values in a column using a dictionary, which is a specific verb+resource combination. It also distinguishes itself from sibling encoding tools by explicitly mentioning use cases like translating codes, merging categories, and creating ordinal mappings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Useful for translating codes, merging similar categories, or creating ordinal mappings'). It does not explicitly mention alternatives or exclusions, but the use cases are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds value by explaining that normalize=True shows percentages instead of raw counts, which is a key behavior. However, it does not mention how missing values are handled, how the table is structured, or any potential side effects, leaving some gaps for an unannotated read-analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus a concise example, with the core function stated in the first sentence. Every sentence earns its place, and no unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple bivariate analysis tool with an output schema present. The description covers the purpose, usage, and normalization behavior, which is sufficient for basic invocation. The lack of df_name explanation is a minor gap, but overall the description is complete enough given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 index_col, columns_col, and normalize (via the example and the normalize=True note). However, it does not explain df_name at all, leaving a required parameter (defaulting to '') ambiguous. The example helps but does not fully offset the missing df_name semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Cross-tabulation of two categorical columns', which uses a specific verb and resource, clearly distinguishing it from sibling tools like pivot_table or get_value_counts. It also immediately mentions optional normalization, further clarifying its primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Understand relationships between two categorical variables' provides clear context for when to use this tool. It does not explicitly mention alternatives or exclusions, but the use case is well implied for an agent selecting among similar analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses a useful default behavior (empty numeric_columns uses all numeric columns), but does not mention whether the operation is read-only, side effects, or requirements like column types. Moderate transparency for a simple stats tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the tool's purpose, followed by an efficiency note and an illustrative example. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are documented externally. The description covers key inputs and a default behavior, though it omits df_name semantics. Given the tool's simplicity, this is nearly complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters, so the description must compensate. It explains the numeric_columns default behavior and provides an example for group_column and numeric_columns, but df_name is never explained. Partial compensation for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes descriptive statistics (mean, median, std, min, max) per group for numeric columns. It also distinguishes itself from sibling group_aggregate by noting it replaces many separate group_aggregate calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool instead of many group_aggregate calls, providing clear usage context. It gives a concrete example, but it does not specify situations where group_aggregate might be preferred, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the formula and purpose but does not disclose whether the transformation happens in-place or returns a new dataframe, how missing values are handled, or what the output structure looks like. This is useful but incomplete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver the core formula, the use case, and an example. Every sentence is purposeful and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with an output schema, the description is mostly complete: it gives the transformation formula, a usage rationale, and an invocation example. The main gap is the unexplained 'df_name' parameter and lack of side-effect details, but overall it provides enough to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The 'columns' parameter is clarified via the formula and example, but 'df_name' is not mentioned at all, leaving its meaning and default behavior ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the operation ('Replace each category with its frequency (count / total rows)') with a specific resource and effect. It also distinguishes itself from sibling encoding tools by emphasizing frequency preservation and the no-target-variable use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Useful for initial exploration or when no clear target variable exists,' which provides clear context vs alternatives like target_encode. However, it does not name specific alternative tools or give 'when-not-to-use' guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 a key behavioral trait: new columns are created (named Log_{column}), which implies original columns are preserved. However, it doesn't describe behavior on missing values, non-numeric columns, or whether the dataframe is modified in place. The df_name parameter's role is also unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive. The main purpose is stated first, followed by method details, usage guidance, a verification tip, and a concrete example. Every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and presence of an output schema, the description covers the essential aspects: purpose, methods, when to use, and an example. It lacks explanation of df_name but otherwise provides a complete picture. The mention of plot_histogram for verification adds helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the 'method' parameter with options and meanings, and the 'columns' parameter through examples and naming convention. However, the 'df_name' parameter is not explained, leaving a gap for one of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a log transform to columns, specifying the verb 'Apply' and resource 'columns'. It also mentions the new column naming convention 'Log_{column}' and lists supported methods, making it distinct from sibling transformation tools like normalize or clip_outliers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use: on right-skewed distributions with |skewness| > 1. It also recommends 'log1p' as the safest method and suggests verifying results with plot_histogram. It doesn't explicitly mention when not to use or name alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It explains model-agnostic nature, measurement on test data, and that it shows error bars from multiple random shuffles, indicating stochastic behavior. It does not mention potential computational cost or return format, but adds meaningful context beyond the bare name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the core definition, and each sentence adds value. The example is compact and directly illustrates usage without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, no annotations, and no output schema, the description covers the what and why but omits the return value or how results are presented. It also does not specify prerequisites or error scenarios, leaving some gaps for a tool with 6 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 6 undocumented parameters. It only mentions 'model_name' and 'test_df_name' in the example and hints at 'n_repeats' via 'multiple random shuffles', but leaves 'top_n', 'save_path', and 'target_column' unexplained. This is insufficient for proper parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'model-agnostic feature importance measured on test data' and contrasts with 'built-in feature_importances_', which aligns with the sibling tool 'feature_importance'. This distinguishes the tool's purpose and resource clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to prefer this tool ('More reliable than built-in feature_importances_') and implies it should be used on test data. It provides a concrete example invocation, but lacks explicit exclusions or prerequisites like requiring a trained model or existing dataframes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses several behavioral traits: lower triangle mask, method options, and the meaning of empty columns (all numeric). It also implies a prerequisite. Lacks details on save_path side effects or return value, but with no annotations, it covers the key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no fluff. Each sentence adds value: what it does, method options, column semantics, usage timing, purpose, and an example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core functionality and usage context are clear, but two parameters are left undocumented and there is no mention of how it compares to related tools like get_correlation or correlation_filter. It is adequate for a typical plotting task but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains method options and columns default, but df_name and save_path are completely unmentioned. This is only partial compensation for 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a correlation heatmap with a lower triangle mask and annotations, which is a specific verb+resource. It distinguishes itself from sibling plotting tools by specifying the correlation focus and the mask/annotation behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use it ('Run after all numeric features are prepared') and what it identifies (multicollinearity and target correlations). However, it does not explicitly mention alternatives or exclusions, though the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral disclosure. It discloses useful behavior (KDE overlay, log scaling) and even warns that a histogram on skewed data is unreadable without log scaling. However, it leaves out important details such as what the function returns, whether it displays the plot, how save_path influences behavior, and how the dataframe is selected (df_name).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and followed by one sentence of usage guidance and a valuable example. Every sentence earns its place, with no redundant or trivial content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a plotting tool with six parameters, no output schema, and no annotations, the description delivers a solid overview: purpose, use case, parameter advice, and an example. The only gaps are the unexplained df_name and save_path parameters and lack of output/return details, which prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% property descriptions, so the description must compensate. It explains column, bins, kde, and log_scale, and provides a concrete example. However, df_name and save_path are not described, leaving two of six parameters without semantic guidance beyond their names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific action: 'Plot a histogram for a numeric column' and mentions optional KDE overlay and log scaling. This distinguishes it from sibling plot tools (e.g., plot_bar, plot_scatter) and precisely communicates the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly places the tool in the EDA workflow ('Use during EDA to understand numeric distributions') and provides actionable guidance on when to enable log_scale for skewed data and to check for bimodality. It does not reference alternative tools, but the context given is clear and specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It states that predictions are stored as a new column and mentions the requirement for matching feature columns, which adds some transparency. However, it does not clarify whether the dataframe is modified in place, what happens if the prediction_column already exists, or any side effects beyond adding a column.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences covering purpose and prerequisite, plus an illustrative example. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a prediction tool with an output schema, the description adequately covers the core function, prerequisite, and usage within a modeling pipeline. It does not need to explain return values given the output schema. It might be slightly more complete with error conditions, but this is sufficient for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to parameters. The example shows model_name and df_name usage, but does not explicitly describe each parameter's role or constraints. The parameter names are somewhat self-explanatory, but the description does not fully compensate for the lack of schema descriptions, especially for prediction_column.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate predictions on a dataframe using a stored model' and mentions it 'Stores predictions as a new column.' This specific verb+resource phrasing distinguishes it from sibling tools like train_model or evaluate_model. The example further clarifies its role in 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, stating it generates predictions on new data and that the dataframe must contain the same feature columns used during training. It implies this is for inference after model training, but does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly details the output contents and implies a read-only operation, though it does not explicitly state that it modifies nothing. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: one lists contents, one gives a usage directive, one reinforces the value. Each sentence earns its place, though the first sentence is slightly dense with metrics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return types are likely defined. The description covers the scope of the report and provides essential usage context. For a single-parameter tool, this is sufficiently complete, though it could mention whether the tool accepts only the current dataframe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the single 'df_name' parameter, and schema coverage is 0%. The schema only provides the title 'Df Name' and a default empty string, which is minimal. The description fails to explain what to pass or how the parameter relates to the current dataframe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Comprehensive data quality report') and enumerates the exact metrics (dtype, missing values, uniques, duplicates). This clearly distinguishes it from sibling tools like get_info, get_column_profile, and get_statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks it as the 'ESSENTIAL FIRST STEP after loading data' and instructs to run it before any cleaning or transformation, giving strong temporal guidance. It does not name alternative tools or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses one key behavior, 'Types are auto-cast,' which helps with type mismatches. However, it doesn't state whether the operation mutates the dataframe, how missing values are handled, or whether the replacement is exact/substring. With no annotations, these crucial behaviors remain undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus an example, with no fluff. It front-loads the core action and uses whitespace effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple value-replacement tool, it includes appropriate usage context, a concrete example, and auto-cast behavior. The output schema covers return values, so that absence isn't an issue. It would benefit from mentioning df_name and mutation behavior, but the overall package is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The example explains column, old_value, and new_value, but df_name is never mentioned. Since schema descriptions are absent, the description should cover all parameters. It covers three of four, leaving potential confusion about targeting a specific dataframe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Replace a specific value with another in a column.' The example provides concrete usage, and the sentence 'Fix known data entry errors or standardize values' clarifies intent. This distinguishes it from nearby siblings like apply_mapping by focusing on single value replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use after identifying issues with get_unique_values,' giving a clear precondition. It doesn't mention alternatives or when not to use it, but for a simple tool the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains the score range and interpretation thresholds, and gives a usage example. It does not explicitly state that the operation is read-only or mention potential side effects, but for a simple compute tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, followed by interpretation, usage guidance, and an example. Every sentence adds value and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 parameters and an output schema. The description covers purpose, when to use, and interpretation, but parameter semantics are weak, and the description does not explain the df_name parameter or the nature of feature_columns beyond the example. Overall, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 provides an example that shows cluster_column and feature_columns usage, but does not explain what these parameters mean semantically, nor does it mention the optional df_name parameter. The example gives minimal insight but is not adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'compute' with a clear resource 'silhouette score' and states it evaluates clustering quality. This distinguishes it from sibling tools like kmeans_cluster, dbscan_cluster, and cluster_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Run after kmeans_cluster or dbscan_cluster.' It provides clear context for the intended workflow, though it doesn't mention when not to use it or alternative evaluation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 mean calculation, the default behavior when feature_columns is empty (all numeric columns), and includes an example. This adds meaningful behavioral detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences plus an example, with the core purpose front-loaded. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the main behavior well. However, it misses the df_name parameter semantics, which is needed for complete understanding of how the tool is invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains feature_columns (and its default behavior) and gives an example showing cluster_column usage. However, it completely omits df_name, which is a required parameter in practice, leaving a semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes descriptive statistics (mean of each feature) per cluster, with a specific verb and resource. It also adds context on usage ('to understand what characterizes each cluster'), distinguishing it from general statistics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use to understand what characterizes each cluster,' providing a clear when-to-use scenario. It doesn't mention alternatives or exclusions, but the context is sufficient for a specialized profiling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the axis parameter and gives an example, but does not disclose the return behavior, how result_name is handled when empty, or whether input dataframes are modified. This is adequate but leaves key behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus an example, with no fluff. It front-loads the core action and immediately gives a practical use case, making every sentence valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic functionality well, it lacks details on result_name behavior, error conditions (e.g., mismatched columns), and whether the operation is in-place or returns a new dataframe. Given the absence of annotations, this leaves some important gaps for full autonomous usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explicitly clarifies 'names' (list of dataframes) and 'axis' (0 or 1) through the example, and the purpose of 'result_name' is inferable. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool concatenates multiple dataframes along rows or columns, with a specific verb (concatenate) and resource (dataframes). It also provides an example and mentions common use cases, distinguishing it from siblings like merge_dataframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers clear context on when to use the tool ('Combine train and test sets back together, or append new data'), but it does not explicitly name alternatives or state when not to use it. This is a minor omission, so a 4 is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It explicitly warns 'modifies in-place' and advises using `copy_dataframe` first, which is a critical behavioral disclosure. It also explains the open-ended range behavior, but does not cover edge cases like invalid column names or inclusivity of the range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose, parameter details, warning, and example. The sentence 'Subset data to a specific time period' is somewhat redundant with the first sentence, but the overall organization is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, parameter behavior, in-place mutation, and includes an example. Given an output schema exists, return values need not be explained. However, the unexplained `df_name` parameter and missing details about validation or inclusivity create minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the format and semantics of `start` and `end` (ISO strings, open-ended) and gives an example for `column`. However, `df_name` is completely ignored, and the `column` parameter is only demonstrated, not explicitly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Filter rows by datetime range', using a specific verb and resource. It distinguishes itself from the generic sibling `filter_rows` by specifying the datetime-range scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: explains open-ended ranges by leaving start/end empty, and includes a concrete example. However, it does not explicitly mention when not to use this tool or mention alternatives such as `filter_rows`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It explains the effect of subset and keep parameters, but fails to mention whether the operation modifies the input dataframe in place or returns a new one. This is a significant behavioral gap for a data manipulation tool, especially given the df_name parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it states the core action first, then parameter definitions, a usage tip, and an example. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 an output schema, the description covers the main functionality but misses important contextual details such as the meaning of df_name and whether the operation is in-place or returns a new dataframe. These omissions could lead an agent to use the tool incorrectly, though the example and usage tip mitigate some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains two of the three parameters: subset ('columns to check (None = all)') and keep ('first', 'last', or 'none'). It also provides a concrete example demonstrating usage. However, the df_name parameter is left unexplained, which is a gap since the schema provides no description. Overall, the core parameters are well covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Remove duplicate rows,' a specific verb and resource that clearly identifies the tool's function. This distinguishes it from sibling tools like drop_columns or drop_missing, and the additional explanation about subset and keep parameters reinforces its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool: 'Run early in pipeline, right after EDA,' and explains why duplicates are problematic ('Duplicates inflate statistics and bias models'). While it does not explicitly state when not to use it or mention alternatives, the context is sufficiently clear for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the how and subset logic, but does not disclose whether the operation modifies the dataframe in-place or returns a new one, nor does it mention any effects on the current dataframe. It also omits the df_name parameter entirely. The core behavior is clear, but operational side effects are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences plus a clear example. It front-loads the primary action, explains parameters efficiently, and provides a usage example. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and an output schema exists to explain return values. However, the description omits the df_name parameter and does not clarify whether the operation is in-place or returns a new dataframe. Given the lack of annotations and 0% schema coverage, these gaps make the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'how' and 'subset' with defaults and examples, but the 'df_name' parameter is never mentioned. Two of three parameters are well-covered, but the missing df_name is a notable gap given the absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Drop rows with missing values.' It further defines the two modes of operation (how and subset) and differentiates from fill_missing by specifying when to use each. This is a specific verb+resource description with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use when entire rows are invalid. For partial missingness, prefer fill_missing instead.' This directly tells the agent when to use this tool versus the sibling fill_missing tool. The example further clarifies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the tool returns classification or regression metrics, emphasizes the test-set requirement, and includes a practical example. While it doesn't cover every edge case (e.g., target_column handling), it provides substantial behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, followed by metric details, a critical usage caveat, and an illustrative example. Every sentence earns its place without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which presumably documents return structures) and the clear enumeration of metrics, the description is largely complete. However, it could better situate the tool relative to cross_validate or compare_models, and it omits target_column semantics. Still, for a straightforward evaluation tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only demonstrates model_name and test_df_name via the example, leaving target_column entirely unexplained. The parameter names are somewhat self-explanatory, but the missing target_column guidance creates ambiguity, especially when it is optional (has default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Evaluates a model on test data' and enumerates the specific metrics returned. It distinguishes from siblings like 'predict' (which generates predictions) and 'train_model' (which trains a model), making the purpose unambiguous. The example reinforces the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'Always evaluate on TEST set, never training set' and advises comparing metrics against baseline to detect overfitting, providing clear context for interpretation. It does not explicitly name alternative tools for cross-validation, but the guidance is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a read-only behavior that returns first N rows as a formatted table, with no side effects. It does not cover edge cases like an empty df_name, but for a simple head operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: action, usage context, and example. The description is front-loaded with the core purpose and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, and output format ('formatted table') with an example, which is sufficient for a simple tool. However, it omits df_name semantics and selection behavior, a meaningful gap in the dataframe context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only indirectly explains n via 'first N rows' and the example get_head(n=10). df_name is completely unaddressed, and with 0% schema description coverage, the description fails to compensate for the missing parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the first N rows of the dataframe as a formatted table', specifying a verb, resource, and format. The phrase 'Quick first look after loading' differentiates it from other inspection tools like get_tail and get_info by emphasizing initial data verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Quick first look after loading. Verify data loaded correctly and understand structure.' This provides clear context, though it does not explicitly name alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the exact output structure: 'count, mean, std, min, quartiles, max for numeric; count, unique, top, freq for categorical.' This is significant transparency for a descriptive statistics tool, even though safety aspects like read-only behavior are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero fluff. The first sentence states the purpose, the second lists output components, and the third gives usage guidance. Every sentence earns its place, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a descriptive statistics tool, the description covers purpose, output, and workflow placement. The only missing piece is the meaning of df_name, but the existence of an output schema and the clarity of the rest make this relatively complete. A score of 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (df_name) with 0% schema description coverage, so the description must compensate. However, the description does not mention df_name at all, leaving the agent to infer its meaning from the parameter name alone. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get descriptive statistics for all columns (numeric and categorical).' This is a specific verb+resource combination that differentiates it from siblings like get_column_profile (which targets single columns) and quality_report (which is a broader report).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Run after quality_report to decide cleaning strategies.' This indicates the typical workflow placement but does not explicitly mention when NOT to use the tool or name alternatives. This matches a score of 4 (clear context but no exclusions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the mapping behavior (unique values to integers starting from 0) but does not mention side effects such as whether the dataframe is modified in place, how missing values are handled, or whether new columns are created. The output schema exists but is not shown; still, key behavioral traits remain unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: a clear purpose statement, explicit usage guidance with alternatives, and a practical example. Every sentence adds value, and the most critical information (what and when) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of annotations, the description is mostly complete: it explains the operation, provides usage constraints, and gives an example. However, it omits details about the 'df_name' parameter and mutation behavior, which are relevant for execution. The existence of an output schema partially mitigates the need to explain return values, but operational ambiguities remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the 'columns' parameter via example ('columns=["City","Category"]') but does not explain 'df_name' at all. This leaves one of the two parameters undocumented in both schema and description, creating a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Label-encode categorical columns: map each unique value to an integer (0, 1, 2, ...)'. It uses a specific verb ('map') and resource ('categorical columns'), and distinguishes itself from sibling tools by explicitly naming alternatives (one_hot_encode, target_encode) for nominal data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use ONLY for ordinal data with natural order (e.g., low/medium/high, small/large)'. It also gives a clear exclusion and alternatives: 'For nominal categories without order, use one_hot_encode or target_encode'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key side-effects: the loaded dataframe becomes the current active dataframe and the name defaults to the filename. It does not cover error handling or file limitations, but the provided behavioral context is valuable and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action, followed by necessary workflow context. All three sentences add value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description places the tool within the overall pipeline ('first step', 'quality_report') and mentions the active-dataframe side-effect, which is critical for using sibling tools. Since an output schema exists, return-value details are not required, though encoding or large-file behavior could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the 'name' parameter's default behavior, but 'separator' is entirely undocumented and 'file_path' is only implicit. For a loader with three parameters, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Load') and resource ('CSV file'), clearly distinguishing this from sibling loaders like load_excel and load_parquet. It also states its role as the first step in a pipeline, which differentiates it from other data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Always the first step in any pipeline' and advises running quality_report immediately after loading. It does not explicitly contrast with load_excel/load_parquet, but the clear 'CSV' scope and pipeline ordering provide strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: features are auto-standardized, PC columns are added, and a 2D scatter plot is stored when plot=True. This goes beyond simple operation statements, though it doesn't specify whether original columns are preserved or how save_path affects output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a short paragraph followed by a concrete example. It avoids verbose explanations, but the example adds a line that could be seen as extra; still, it earns its place by illustrating parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's moderate complexity, the description covers the key outcomes (new columns, plot storage) and usage scenarios. It doesn't explain return values because output schema exists, and no annotations mean it handles safety disclosure well enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the purpose of columns, n_components, plot, and hue via the example, but df_name and save_path are not explicitly described. The example provides practical parameter mapping, but not all parameters are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs PCA dimensionality reduction, projects numeric columns onto principal components, and adds PC columns to the dataframe. This specific verb+resource pairing distinguishes it from siblings like tsne_plot, which uses a different algorithm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use to visualize high-dimensional data, reduce multicollinearity, or compress features.' This provides clear usage context, though it does not name alternative tools or when not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the tool plots value counts for top N categories and supports vertical/horizontal orientation, but does not disclose whether it modifies data, displays vs. saves the plot, or how df_name/save_path are used. Some useful details are present, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: one sentence stating the core functionality, followed by usage rationale, and a clear example. No filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's main purpose and provides a usage example, but with no output schema and 5 parameters, it omits details about df_name and save_path and does not clarify the return value (e.g., shows a plot object). It is minimally complete for a simple plotting tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The example `plot_bar(column="CargoType", top_n=10, orientation="horizontal")` clarifies the meaning of column, top_n, and orientation. However, df_name and save_path are not explained, leaving ambiguity for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: "Bar plot of value counts (top N categories)" with a specific verb and resource. It distinguishes from sibling plot tools by focusing on categorical value counts, making it easy to select for categorical distribution analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: "Understand categorical distributions during EDA. Reveals rare categories for potential grouping and dominant categories for stratified sampling." This indicates when to use the tool, but it does not explicitly name alternatives or exclusions (e.g., when not to use it).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly mentions the destructive action 'Drops non-matching columns' and clarifies the effect of the include/exclude parameters. It does not mention whether the operation modifies the original dataframe or returns a new one, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly efficient, front-loading the purpose. It has some redundancy ('Keep only columns' vs 'Filter columns by type') and repeats examples twice. It is not overly long and every sentence adds some value, but tightening it would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the existence of an output schema (which reduces the need to explain returns), the description covers the main use cases, provides examples, and mentions the modeling context. It lacks details on df_name and edge cases, but overall it is sufficiently complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 include and exclude via examples, but df_name is not mentioned at all. Also, it does not enumerate valid dtype strings or handle the case when both include and exclude are set. Thus, it partially compensates but lacks full parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb+resource: 'Keep only columns matching specified dtypes' and 'Drops non-matching columns.' This distinctively separates it from sibling tools like drop_columns (which removes by name) or convert_dtype (which changes types). The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete usage context: 'Use include=['number'] before modeling to keep only numeric features.' This implies when the tool is useful. It also gives examples for include and exclude. However, it does not explicitly name alternatives or state when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states the tool is non-destructive, returns a list, and does not auto-drop. The example further clarifies threshold usage. It does not disclose edge cases (e.g., behavior with zero-variance vs near-zero), but for a simple filter tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, front-loaded with the main action, and includes a return type, a non-destructive note, a rationale, and a concrete example. Each sentence earns its place, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema exists, and the description covers core behavior, non-destructive nature, and threshold semantics. It lacks an explanation of df_name and does not explicitly differentiate from correlation_filter, but overall it is sufficient for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the threshold parameter via 'variance at or below threshold' and the example with threshold=0.01. However, the df_name parameter is never described, leaving its role unclear. The description only partially compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it identifies columns with variance at or below a threshold and returns a list of low-variance columns. It also explicitly mentions 'Does NOT auto-drop' to distinguish it from drop operations like drop_columns or drop_low_importance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting low-variance columns are constant/near-constant and 'provide no useful information for modeling.' It implies use for feature inspection before dropping, and 'Does NOT auto-drop' hints at the alternative of using drop tools, though it does not explicitly name them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It describes the test's purpose and example usage, but does not mention important behavioral aspects such as statistical assumptions (e.g., normality, homogeneity of variances), required data types beyond the example, or whether the tool is read-only. Thus it provides some context but is missing deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at only four sentences, each adding distinct value: definition, purpose, alternative, and example. There is no fluff or repetition, making it efficient and well-organized for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is largely complete: it explains what the tool does, when to use it, and includes an example. However, it omits any mention of the 'df_name' parameter and does not explicitly state input preconditions (e.g., numeric column type). These gaps slightly reduce completeness, but the core functionality is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, so the description must compensate. It does so partially by showing an example with 'column="Revenue"' and 'group_column="FlownMonth"', implying these are column name strings. However, the third parameter 'df_name' is not mentioned at all, and the description doesn't explicitly state the nature of the columns (numeric vs categorical). Thus it adds some meaning but leaves a gap for the unmentioned parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a one-way ANOVA test that compares means of a numeric column across 3+ groups, using the specific verb 'compares' and a specific resource. It also distinguishes itself from sibling tools like ttest_independent by explicitly noting the 3+ group requirement, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use to determine if at least one group mean differs significantly from the others') and when not to use it, by providing the alternative 'For exactly 2 groups, ttest_independent is more appropriate.' This gives clear usage guidance and naming an alternative, which is exactly what is expected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently states that it uses cross-validation, returns a ranked table, and adapts default models based on target type. It does not disclose potential computational cost or side effects, but for a read-only comparison tool, this is sufficient. No contradiction with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the core action, the second gives the value proposition, the third explains defaults, and the fourth provides a concrete example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a model comparison tool with an output schema, the description covers the main aspects: purpose, return value, defaults, and an example. It does not explain df_name or n_folds parameters in the text, but these are common across sibling tools and have sensible defaults. The presence of an output schema reduces the need to describe return format in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 model_types by giving defaults and conditional behavior ('or classifiers if target is categorical') and shows an example with target_column. However, n_folds and df_name are not explicitly explained, though their names and schema defaults provide some context. Partial compensation warrants a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare multiple model types using cross-validation. Returns a ranked table.' It uses a specific verb (compare) and resource (model types), and distinguishes itself from sibling tools like train_model and evaluate_model by focusing on comparison before hyperparameter tuning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use the tool: 'Quick way to find the best model type before fine-tuning hyperparameters.' This implies the tool is for initial model selection, but it does not explicitly mention alternatives or when not to use it. It also notes the default behavior, adding practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool creates a new numeric column and lists available units, which is useful. However, it does not state whether the operation modifies the dataframe in-place or returns a new one, nor does it explain behavior with missing values or non-datetime inputs. This leaves important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core function. It includes units, output type, use case, and an example in just four sentences, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 parameters and no annotations. The description covers purpose, units, output, and example, but omits df_name semantics and does not clarify whether the operation alters the existing dataframe. These gaps prevent a perfect score, but overall it is fairly complete for a transformation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explains column_a and column_b as datetime columns, new_column as the output name, and unit as days/hours/minutes/seconds via text and example. However, df_name is completely undocumented in both schema and description, leaving a gap in parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool computes time difference between two datetime columns using column_a - column_b, which is a specific verb+resource. It also distinguishes from siblings like extract_datetime_parts and datetime_filter by clearly targeting duration calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Create duration features between two dates (e.g., delivery time, age, tenure)'. However, it does not mention alternatives or when-not-to-use, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses conditional numeric behavior ('if numeric'), caps value frequencies at top 10, and includes null/unique counts. This is substantive and goes beyond a generic 'analyze' statement, though it does not mention error handling or whether the dataframe is mutated (implied read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most important output list, then moves to use cases and a concrete example. Every sentence adds value without redundancy; it is compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (so return format is covered), the description provides sufficient context for a single-column analysis tool: what it computes, when to use it, and how to invoke it. The only notable gap is the undocumented df_name parameter, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarifies the 'column' parameter through the example get_column_profile(column="Revenue") and the 'one column' wording, but it does not explain the optional df_name parameter beyond the schema's title/default. This is partial compensation, not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Detailed single-column analysis' and enumerates specific outputs (dtype, nulls, unique count, statistics, top 10 frequencies), making the tool's purpose and scope unambiguous. It clearly differentiates from sibling tools like get_statistics and get_unique_values by focusing on a single-column deep-dive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States explicit trigger: 'Use when quality_report flags something' and connects output to follow-up action: 'Provides skewness for deciding if log_transform is needed.' It lacks an explicit when-not or named alternatives, but the use context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key side effects: it saves the best model for later predict/evaluate and returns the best parameters and score. This goes beyond a simple 'does grid search' by explaining the model persistence behavior, though it doesn't mention error conditions or parameter-specific effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, front-loading the purpose and using a compact example to clarify usage. Each sentence contributes unique information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core behavior, return value, and side effect, and the example clarifies common parameters. However, it omits explanations for the optional parameters and prerequisites, which would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The example adds meaning to the required parameters (target_column, model_type, param_grid) by showing concrete values and the structure of the param_grid dictionary. However, the description does not explain n_folds, model_name, or train_df_name, which is a gap given the schema has 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs grid search for hyperparameter tuning, testing all combinations and saving the best model. This distinguishes it from sibling tools like train_model or cross_validate by emphasizing exhaustive search and model persistence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's for hyperparameter tuning, which tells an agent when to use it. However, it doesn't explicitly mention alternatives or when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the test is non-parametric and does not assume normality, which is relevant. However, it does not mention the return value (though an output schema exists) or any edge cases like missing data handling or the role of df_name. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear definition, usage guidance, and an example in just three sentences. Every sentence adds value, and the example is practical without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is largely complete. It covers purpose, applicability, a concrete example, and distinguishes from related tests. The only minor gap is the undocumented df_name parameter, but its default value reduces the risk of confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description clarifies that 'column' is numeric and 'group_column' represents groups. The example 'kruskal_wallis_test(column="Revenue", group_column="FlownMonth")' shows the two required parameters in context. However, the third parameter 'df_name' is not explained at all, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a Kruskal-Wallis H test, a non-parametric alternative to ANOVA, and explicitly says it compares distributions of a numeric column across 3+ groups. This is a specific verb-plus-resource statement that also distinguishes it from the sibling mann_whitney_test by noting the group count difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance (when normality_test indicates non-normal data) and an explicit alternative (use mann_whitney_test for 2 groups). This directly addresses usage context and differentiates from related sibling tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the file is loaded into memory and that the name parameter defaults to the filename, adding useful behavioral context. However, it does not discuss memory implications, error behavior, or whether the operation is read-only beyond the implied 'load' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states the purpose, the second provides rationale for preferring Parquet, and the third gives a default behavior and example. It is appropriately sized and front-loaded, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple load tool, the description covers all essential aspects: what it does, when to use it, an example, and a default behavior. An output schema exists, so return values need no explanation. It lacks caveats about file size or format specifics, but this is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does so by providing an example using file_path and explicitly stating that name defaults to the filename. This gives meaning to both parameters, though it does not fully elaborate on the purpose of the name parameter beyond its default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Load a Parquet file into memory,' a specific verb+resource statement that clearly defines the tool's function. It also distinguishes itself from sibling load tools by explicitly naming the Parquet format, setting it apart from load_csv and load_excel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating that Parquet is columnar and much faster than CSV for large files, implying when this tool should be preferred over load_csv. However, it does not explicitly name alternative tools or mention when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 a key behavior (result stored as a new dataframe) and warns about join key verification, but does not describe error handling, duplicate key behavior, the default 'inner' already in the schema, or side effects on input dataframes. It adds some transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
All five sentences are purposeful and front-loaded with the core action. There is no redundant phrasing, and the descriptive content efficiently covers the operation, parameters, and usage prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation, usage context, and a key prerequisite. It does not mention parameter-specific details like how multiple join keys are handled or the default behavior when result_name is omitted, but with no schema descriptions and no annotations, it provides a usable baseline. The complexity of SQL JOIN is moderate, and the description is sufficient for an agent to select and call the tool with minimal guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explicitly lists valid values for 'how', implies 'left_name'/'right_name' via 'two dataframes', implies 'on' via 'join keys', and implies 'result_name' via 'stored as a new dataframe'. However, it does not explicitly map each parameter name to its meaning, so a slight deductive leap is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'merge' and clarifies with 'like SQL JOIN', immediately distinguishing from concat_dataframes among siblings. The 'How' options further clarify the join types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case ('when data is split across files') and a prerequisite ('verify join keys exist... with get_info first'). It does not explicitly state when not to use it or name alternative tools, but the SQL JOIN analogy implicitly differentiates from concat_dataframes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions aggregation and the pivot table format, which gives some insight. However, it does not describe side effects such as whether the plot is displayed or saved (save_path parameter), nor does it mention requirements like numeric values for the metric or handling of missing data. This is a noticeable gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core definition, followed by a clarifying elaboration and a concrete example. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is fairly complete. It explains the main purpose, provides a worked example, and differentiates from siblings. However, it lacks details about df_name and save_path behavior, and does not state the expected return/output (e.g., display or save), which would be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 provides an example that clearly explains the core parameters: index_col and columns_col as the two categorical dimensions, values_col as the metric, and agg_func as the aggregation function. This covers most of the important parameters, though df_name and save_path are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 creates a heatmap of aggregated values in a pivot table format, showing a color-coded matrix of one metric across two categorical dimensions. This specific verb+resource (plot heatmap) and the explicit illustration with an example distinguish it from sibling plotting tools like plot_scatter and plot_bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use this when you want to visualize aggregated values across two categorical dimensions. The example demonstrates exactly how to call the tool. However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behaviors (degree=2 creates x^2 and x1*x2, interaction_only=True skips powers). However, it does not state whether the tool modifies the existing dataframe or returns a new one, nor how df_name is used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences total: purpose, parameter behavior, usage guidance, and an example. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations, the description covers the core transformation, usage context, and example. The output schema likely covers return values, so the main gap is the lack of explanation for df_name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 degree and interaction_only in behavioral terms and provides an example for columns. df_name is left unexplained, but the other parameters receive meaningful elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Create') and resource ('polynomial and interaction features from numeric columns'), clearly distinguishing it from sibling feature engineering tools. It also explains the behavior of degree and interaction_only, making the function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use when linear models underfit: polynomial features capture non-linear relationships,' which is clear context for when to apply the tool. It does not mention exclusions or alternatives, but the guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It accurately describes the transformation (smoothed mean replacement), introduces the smoothing parameter, and warns about the data leakage pitfall. It does not explicitly state whether the operation mutates the dataframe in place or returns a new one, but the phrase 'Each category is replaced' implies in-place modification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, all of which are informative and directly relevant. It does not waste words and the example provides a clear, concrete usage pattern. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage conditions, a critical warning, and includes a concrete example. With an output schema present, return values need not be explained. The only notable gap is the undocumented df_name parameter, but overall the description is well-rounded for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions the columns, target_column, and smoothing parameters in the example and text, but does not describe df_name at all. The meaning of smoothing is only partially explained as 'smoothed mean' without detailing how the numeric value affects the encoding, leaving ambiguity about its exact role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Target-encode high-cardinality categorical columns') and explains the mechanism ('Each category is replaced by the smoothed mean of the target variable'), distinguishing it from sibling encoding tools like one_hot_encode, label_encode, and frequency_encode. The mention of 'high-cardinality' and 'smoothed mean' makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Good for columns with many unique values. Best for high-cardinality (>10 categories).' It also gives a critical procedural guideline about data leakage: 'split data first with train_test_split, then encode training set only.' However, it does not explicitly mention when not to use the tool or name alternative encoding methods, 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.
Behavior4/5
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 that features are auto-standardized and that the method is slower than PCA, adding behavioral context beyond the schema. However, it does not explicitly state whether the tool modifies data or simply generates a plot, though the term 'visualization' implies non-destructive behavior. It also does not mention handling of missing values or randomness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately compact: three sentences plus an example. It front-loads the core purpose ('t-SNE visualization'), adds comparative guidance, and gives a concrete usage example. Every sentence serves a purpose, and the example clarifies parameter usage without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, usage context, and a performance caveat, but lacks essential parameter details and return behavior. With 7 parameters and no output schema, an agent still needs to infer the roles of key parameters like perplexity and save_path. The description is adequate for basic orientation but incomplete for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for all 7 parameters. The example mentions columns, perplexity, and hue but does not explain what perplexity, n_components, random_state, df_name, or save_path mean. This is a significant gap, as parameters like perplexity are critical for t-SNE behavior and are not intuitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 't-SNE visualization. Non-linear dimensionality reduction for 2D visualization.' It identifies a specific verb+resource: creating a t-SNE plot. It also distinguishes itself from PCA, a likely alternative among siblings, by noting it is better for clusters and local structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Better than PCA for revealing clusters and local structure' and 'Slower than PCA — best on datasets < 10,000 rows or use sample_data first.' This directly tells the agent when t-SNE is preferable to PCA and cautions about dataset size, helping select between this and sibling pca_transform.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains that p < 0.05 means the data is NOT normal, and it lists method constraints (sample sizes). This provides an understanding of the test's interpretation and operating assumptions, going beyond a mere 'tests normality.' However, it doesn't mention how missing values or non-numeric data are handled, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action, followed by method details, usage context, and an illustrative example. Every sentence adds value, with no fluff or redundancy. The structure flows logically from purpose to method to interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description covers all necessary aspects: what it does, how to choose a method, when to apply it, and how to interpret results. The example ties everything together. It does not need to explain return values since an output schema exists. The description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clearly describes the 'column' parameter as a numeric column and explains the 'method' parameter with options ('shapiro', 'ks', 'dagostino') and their suitability. However, the 'df_name' parameter is not mentioned at all, leaving its purpose ambiguous. The example shows usage but does not clarify df_name's role, so compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear, specific verb and resource: 'Test if a numeric column follows a normal distribution.' It distinguishes this tool from sibling statistical tests (like ttest_independent or anova_test) by focusing on normality. The method list and example further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use before deciding on parametric vs non-parametric tests.' It also provides method selection guidance based on sample size (e.g., 'shapiro' for n < 5000, 'dagostino' for n >= 20). While it doesn't name specific alternatives, this is clear contextual guidance for using the tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It explicitly states 'Non-destructive' and 'does NOT drop them', and explains the return value (list of low-importance columns with correlation values). This gives the agent a clear understanding of side effects and outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, front-loading the primary purpose in the first sentence, then adding return behavior, a non-destructive note, and an example. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations), the description covers the essential behaviors: what it does, what it returns, and its non-destructive nature. It does not detail the output schema, but that is available as structured data. Minor gaps like edge cases are acceptable, so this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must explain parameter meanings. It does clarify threshold and target_column implicitly ('correlation to target below threshold'), and the example shows method='pearson', but df_name is completely unmentioned. Method's semantics are not explained beyond the default value in the schema. This does not adequately compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies features with correlation to target below a threshold and returns a list of low-importance columns with their correlation values. It also distinguishes itself from the sibling drop_low_importance by explicitly noting it does NOT auto-drop, making its purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating 'Review results before using drop_low_importance', which not only tells when to use this tool (before dropping) but also names the alternative. The example further clarifies how to invoke it with typical parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It mentions that features are auto-standardized and that outliers are labeled as -1, which are important behavioral traits. However, it does not explicitly state the output format (e.g., whether a new column is added), though an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the algorithm name, explains its properties, gives usage guidance, and provides an example. Every sentence adds value without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the essential algorithm characteristics, usage context, and key behaviors, while an output schema exists to document return values. Minor gaps remain for parameter details, but the description is sufficiently complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for any parameters (0% coverage), so the description must compensate. The example 'dbscan_cluster(columns=["Revenue","Weight"], eps=0.5, min_samples=5)' gives concrete context for three parameters, but df_name and cluster_column remain unexplained. The parameter names are somewhat self-explanatory, but the description adds only partial semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as DBSCAN clustering, a density-based method that finds arbitrarily shaped clusters. It explicitly distinguishes itself from k-means by noting that it does not require specifying n_clusters, which separates it from sibling tools like kmeans_cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use when clusters have irregular shapes or when you need outlier detection.' This gives clear context for selection, and the example invocation reinforces the usage pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description proactively discloses the in-place mutation behavior, the auto-casting of values for numeric columns, and the isin operator format. This is essential safety information for users.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, starting with the core operation, then enumerating operators, providing formatting details for isin, a warning, and two illustrative examples. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behaviors: supported operators, isin formatting, numeric auto-casting, and in-place mutation. Given that an output schema exists, the return value doesn't need explanation, making this description contextually complete for typical filtering operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage). The description compensates by explaining operators and value casting, and includes concrete examples showing column, operator, and value usage. However, it leaves the df_name parameter unexplained, and the auto-cast behavior is only mentioned for value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool filters rows based on a condition, listing supported operators. This distinguishes it from sibling tools like drop_duplicates or drop_missing, which have specific removal logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('subset data or remove invalid rows') and warns about in-place modification, steering users to copy_dataframe first when preservation is needed. It doesn't explicitly compare to alternative filter/clean tools but provides sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: default sheet selection when sheet_name is empty, name defaulting to filename, and the openpyxl dependency for .xlsx files. It does not cover .xls dependency or error handling, but these are secondary for a load operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose. Each sentence adds value: file types, default sheet behavior, name default, dependency, and an example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a moderate-complexity tool with 3 parameters and an output schema. It covers the key aspects: what it loads, how sheet handling works, and a usage example. Minor gaps like .xls package requirements exist, but overall the description is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well: it explains the sheet_name empty behavior, name defaulting to filename, and provides an example with file_path. This adds meaning beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Load an Excel file (.xlsx, .xls) into memory.' It specifies the resource (Excel files) and the action (load), distinguishing it from sibling tools like load_csv and load_parquet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it handles .xlsx and .xls files, and the example shows intended use. It does not explicitly mention alternatives or exclusions, but the file-type specificity makes the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that scaling is in-place and explains the three methods, which is useful. However, it does not mention behavior with non-numeric columns, error handling, or the role of df_name. Without annotations, these unaddressed aspects leave some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, then methods, usage guidance, and an example. Every sentence contributes value, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, methods, when-to-use, and includes an example. It lacks explanation of df_name and edge-case behavior, but given the output schema exists and the tool is a standard preprocessing step, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 thoroughly explains the 'method' parameter with definitions for minmax, standard, and robust, and clarifies that 'columns' refers to numeric columns. However, the 'df_name' parameter is not explained, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scales numeric columns in-place, distinguishing it from other preprocessing tools like log_transform or clip_outliers. The verb 'scale' and resource 'numeric columns' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given on when to use normalization (distance-based models) and when not to (tree-based models), along with method-selection advice (use 'standard' by default, 'robust' if outliers remain). This directly addresses the decision process for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the binary column creation, drop_first impact on multicollinearity, and warns about high-cardinality column explosion. However, it does not specify whether the operation mutates the dataframe in place or returns a new one, nor what happens to the original column.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. It front-loads the main purpose in the first sentence, then adds usage guidance, a warning, and a practical example. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 3 parameters and an output schema. The description covers the core purpose, usage boundaries, and an alternative. It falls slightly short by not addressing df_name or the exact return/modification behavior, but overall it provides sufficient context for correct invocation in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 columns and drop_first semantics well, but df_name is not mentioned at all. The title 'Df Name' is somewhat self-explanatory, but with zero schema coverage, more explicit guidance would be expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('one-hot encode') and resource ('categorical columns') with clarifying detail ('creates binary columns'). It clearly distinguishes this from sibling encoding tools like target_encode and label_encode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Best for low-cardinality (2-10 categories)'), a recommended setting ('Always drop_first=True for modeling'), and an explicit alternative for high-cardinality cases ('use target_encode instead'). Also includes a concrete example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the save location ('reports/' folder next to the CSV), default directory behavior, and how include_plots works (saves named plots as PNG, reference syntax provided). It does not mention overwrite behavior or failure modes, but it adds significant context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit long but every sentence adds value: purpose, usage context, file locations, defaults, plot handling, and an example. It could be slightly more compact, but it is well-structured and not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior, defaults, and plotting integration, with an example. However, it omits details like how the markdown file is named, whether existing files are overwritten, and it does not contrast with the sibling save_report_html. These gaps prevent a 5, but the example and default explanation make it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 explains output_dir's default and fallback, include_plots' behavior as saving named plots as PNG, and the example clarifies content as a markdown string. This fully conveys how to use all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a data science report as a markdown file with associated plot images. It specifies the resource (report), format (markdown), and differentiates from siblings like save_report_html by mentioning markdown explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this as the FINAL STEP of an analysis to export a structured, presentable report. This provides clear context, but it does not mention when not to use it or alternative tools (e.g., save_report_html), so it lacks exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral constraint that exactly 2 groups are required, but does not mention assumptions (e.g., normality), equal variances, missing data handling, or the output structure. This is a useful but incomplete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it opens with the test name, states the function, provides usage context, highlights the 2-group constraint, and ends with a clear example. Every sentence earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a statistical test, the description covers the core purpose, usage, and key constraint, plus points to anova_test for more groups. It does not mention assumptions or return values, but an output schema exists, which likely documents the return structure. Given complexity and available structured data, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 clarifies that 'column' must be numeric and 'group_column' must have exactly 2 groups, plus provides an example with concrete values. It does not explain 'df_name', but that parameter is optional and likely standard across siblings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an 'Independent two-sample t-test' that 'Compares means of a numeric column across two groups' and determines statistical significance. This is a specific verb+resource and distinguishes from sibling tests like anova_test by explicitly noting the 2-group requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'Use to determine if the difference between two group means is statistically significant' and provides an explicit exclusion: 'Requires exactly 2 groups in group_column. For 3+ groups, use anova_test instead.' This is clear when-to-use and when-not-to-use guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that the copy is 'deep', implying the source remains unchanged, and that it creates a new name. It doesn't discuss overwrite behavior or error handling, but for a simple copy operation, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, followed by a concise usage tip. Every word serves a purpose; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, simple copy tool, the description covers the operation, the new-name behavior, and the optimal usage timing. The output schema exists, so return value details are unnecessary. Minor details like whether existing names get overwritten are not critical for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the parameter names `source_name` and `new_name` are self-explanatory. The description reinforces the purpose of `new_name` with 'under a new name' and clarifies the operation is a deep copy. While it doesn't explicitly define each parameter, the contexts provided by the description makes the semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Create a deep copy of a dataframe under a new name.' It distinguishes this tool from all sibling manipulation tools by focusing on copying, and no other sibling performs this exact action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use BEFORE any destructive operation (dropping, filtering, encoding) if you may need the original data later.' It does not mention when not to use it or name alternatives, but given there are no alternative copy tools among siblings, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool lists all loaded dataframes and their shapes, which is the core non-destructive behavior. It does not mention edge cases or that it has no side effects, but the simple read-only nature is adequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant wording; the first states the function, the second provides usage guidance. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently covers the purpose and usage context. It is complete for an agent to select and invoke this tool correctly among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter semantics beyond the schema. The baseline of 4 applies as no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'all loaded dataframes' and clarifies the output includes their shapes. This distinguishes it from sibling tools like set_current_dataframe or merge_dataframes by focusing on inventory rather than modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises checking available datasets before switching or merging, giving clear context for when to call this tool. It does not explicitly name alternative tools, but the suggested usage implies it is a precursor to operations like set_current_dataframe or merge_dataframes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it adequately discloses that this is a read-only listing operation. It specifies what is returned (type, training metadata, scores), which is sufficient behavioral information for a non-destructive tool with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The first sentence front-loads the action and result; the second adds practical guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, an output schema exists, and a clear listing purpose), the description is complete. It provides purpose, usage guidance, and expected content without needing to explain return values since the output schema covers them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The description appropriately does not attempt to document parameters that do not exist, and the empty schema already provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all trained models with their type and training metadata, using a specific verb ('List') and resource ('trained models'). This distinguishes it from sibling tools like train_model or evaluate_model, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: 'Check which models have been trained and their training scores before deciding next steps.' This tells the agent when to use the tool, though it does not explicitly name alternatives or when-not-to-use scenarios, keeping it just 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the IQR and quantile methods with formulas, and the positional guidance. However, it does not disclose whether the operation mutates the dataframe in place or returns a new one, nor how non-numeric or missing values are handled. This is useful context but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences: a definition, method details, usage guidance, and an example. Each sentence earns its place with no redundancy. It front-loads the action and immediately explains the methods.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, methods, usage, and an example. Since an output schema exists, return values are already specified. It omits edge-case behavior (e.g., non-numeric columns, missing values), but for a typical data-cleaning tool with this guidance, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 so by explaining the 'iqr' and 'quantile' methods, the meaning of iqr_multiplier via the formula, and the lower/upper quantile parameters. The example clarifies usage. The df_name parameter is not explained, but its default and common usage across the tool family make it less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Clip outlier values in a numeric column.' It clearly distinguishes from sibling tools like detect_outliers (which detects) and filter_rows (which filters), by focusing on the clipping action and the two available methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use AFTER detect_outliers confirms outliers exist' and 'Only clip if outliers are errors; genuine extreme values should be kept.' This gives clear when-to-use and when-not-to-use guidance, naming the prerequisite tool and the design decision around genuine extremes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses method behaviors ('iqr' vs 'zscore' with threshold meanings) and the return payload (count, %, boundary values), which is useful and non-contradictory. It does not explicitly state that the DataFrame is not modified, but the 'Detect' framing and output description make the read-only nature reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences front-load the action, then methods, return values, and workflow. Every sentence adds value and the example is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params and no schema descriptions or annotations, the description covers the core semantics and even specifies the output. The only gap is `df_name`, but the workflow guidance and example keep it usable; an output schema also exists, reducing the need to fully spell out returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no property descriptions (0% coverage), and the description compensates by explaining `method` options, `threshold` meaning, and giving an example that maps to `column`/`method`/`threshold`. The `df_name` parameter is not explicitly described, though the default and example imply it is optional/current dataframe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Detect outliers') and identifies the target resource ('numeric column'), then differentiates itself from the sibling `clip_outliers` by explicitly positioning this as the pre-clipping detection step. It clearly names the two methods and what they threshold, so an agent knows exactly what tool this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance says 'Run BEFORE clip_outliers to quantify outliers and determine if they are errors or genuine' and 'Do not automatically clip without this check.' This gives both when-to-use and an exclusion/alternative behavior. It also gives a concrete example to anchor invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly warns 'Destructive: actually drops columns,' and details what each method does (variance <= threshold, abs correlation <= threshold). However, it does not specify whether the operation modifies in-place or returns a new dataframe, nor what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a one-line summary, a compact method list, a destructive warning, and an example. Every sentence adds value and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and zero schema/annotation support, the description covers the core semantics, destructive behavior, usage timing, and an example. Minor gaps remain around df_name and the return value/result format, but the overall picture is clear enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining the meaning of 'method' values and 'threshold' behavior, and providing an example that maps target_column, method, and threshold. It does not explain the 'df_name' parameter, which has a default but may operate on the current dataframe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Drop') and a resource ('columns') with a clear thresholding condition. It distinguishes itself from sibling tools by explaining the two methods (variance, correlation) and explicitly referencing correlation_filter/variance_filter as prior review steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: 'Use AFTER reviewing results from correlation_filter or variance_filter'. It also provides a concrete example call, clarifying when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses the key behavioral trait of base64 embedding and the auto-replacement of plot references, and demonstrates with an example. It lacks details on edge cases like missing plot files or output_dir behavior, but the core behavior is well-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the main purpose, adds differentiation, explains syntax, and provides an example—all in a compact, high-signal format. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description is complete: it covers purpose, alternatives, usage syntax, and behavior. The output schema exists, so return value details are not required. The description leaves no major gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It clarifies 'content' as markdown content through the example, explains 'include_plots' as a list of plot names to embed, and shows how they interconnect. However, 'output_dir' is left to name inference, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save a data science report as an HTML file with embedded plot images (base64).' It uses a specific verb ('save') and resource ('data science report as an HTML file'), and explicitly distinguishes itself from the sibling tool save_report ('Unlike save_report (markdown + separate PNGs), this produces a single self-contained HTML file').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance on when to use this tool versus the alternative save_report, stating the difference in output format. It also explains how to reference plots and includes a concrete example, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses key behaviors: it stores results with '_train' and '_test' suffixes, stratify behavior, and the importance of random_state. It does not explicitly state whether the original dataframe is modified, but the overall transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the primary action first, followed by important behavioral notes and a clear example. Every sentence adds value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description provides sufficient context: usage timing, parameter guidance, stratification behavior, and an example. It fully equips an agent to use the tool correctly in a data science workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains target_column, test_size, stratify, and random_state, but does not explicitly describe df_name. The example covers all main parameters, compensating well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: splitting a dataframe into train/test sets, with a specific output naming pattern. It distinguishes itself from sibling tools like train_model or evaluate_model by being the explicit preprocessing step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Run BEFORE training any model' and gives practical recommendations like using a fixed random_state and stratify for imbalanced classification. It also includes a concrete example, making it easy for an agent to know when and how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-data-science MCP server](https://glama.ai/mcp/servers/AstyanM/mcp-data-science/badges/card.svg)](https://glama.ai/mcp/servers/AstyanM/mcp-data-science)

Score Badge

Copy to your README.md:

[![mcp-data-science MCP server](https://glama.ai/mcp/servers/AstyanM/mcp-data-science/badges/score.svg)](https://glama.ai/mcp/servers/AstyanM/mcp-data-science)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AstyanM/mcp-data-science'

If you have feedback or need assistance with the MCP directory API, please join our Discord server