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

With no annotations, the description carries the behavioral burden. It discloses the primary side effect—writing an HTML file, with auto-generation when output_filename is empty—and states the return value as the relative path to the saved file. It does not mention overwrite behavior or failure handling for missing chart paths, but it is substantially transparent for a report-builder tool.

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

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

The description is compact and front-loaded: a one-sentence purpose, a one-sentence workflow instruction, and a tight Args list with no redundant prose. Every line contributes necessary information, and the return value is stated briefly.

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

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

For a tool with seven parameters and no annotations, the description covers all parameter semantics, the sequencing requirement, the output behavior, and the return path. The workflow context ('after all chart tools have been run') is sufficient for an agent to invoke it correctly. Minor edge-case constraints are not documented, but the description is complete enough for correct usage.

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

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

Input schema coverage is 0%, so the description must carry parameter meaning, and it does: each argument receives a role, such as 'Title shown on the cover page' and 'one per chart, same order as chart_paths.' The repeated 'same order' instruction is particularly useful. Constraints like equal-length arrays are implicit rather than explicit, but the semantic roles are clear.

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

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

The description opens with a specific verb and resource: 'Render an HTML summary report from a set of pre-generated charts.' This clearly distinguishes it from sibling chart-generation tools, which produce charts, and from export_pdf_report, which exports a PDF. The prerequisite of 'pre-generated charts' also scopes the tool's role precisely.

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

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

The description gives an explicit trigger condition: 'Call this after all chart tools have been run and you have collected their output paths.' This tells an agent exactly when in the workflow to invoke the tool. It does not explicitly name alternatives or state when HTML is preferred over the sibling PDF export, 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.

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

With no annotations, the description carries the full burden and does well: it discloses the non-obvious intersection semantics ('All filter types are applied independently and intersected'), auto-generation behavior for output fields, and the exact return format. It does not explicitly say the source dataset is left unmodified, though 'save the result' implies a new output rather than in-place mutation.

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

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

The description is front-loaded with a one-sentence action summary and a critical filtering-semantics note, then uses a structured Args/Returns layout. Given the 8-parameter surface, the length is justified and every sentence adds information; there is no tautology or filler.

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

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

For an 8-parameter tool with no annotations, the description supplies a complete calling contract: all parameters are explained, the intersection behavior is spelled out, and the return shape is given as a JSON str with dataset_name, dataset_path, and dataset_schema. The only minor omission is the exact date string format, but both datetime params are strings with clear semantics, so this is a small gap.

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

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

Schema description coverage is 0%, but the description fully compensates by documenting all 8 parameters with types, examples, and empty/default behavior. For example, categorical_filters is explained as 'List of (column, value) tuples for exact value matching' with concrete examples, and datetime bounds are marked as inclusive with 'Leave empty' instructions.

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

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

The description opens with the specific verb-resource pair: 'Filter a dataset by categorical, numeric, and datetime criteria, then save the result.' It clearly scopes what the tool does and distinguishes it from sibling tools, which are all chart/report generators rather than dataset subsetting operations.

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

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

The description makes the usage context clear: it is the only tool among the siblings that filters and saves dataset subsets, so an agent can infer when to choose it over the visualization/report siblings. However, it does not explicitly name alternatives or state 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.

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

With no annotations, the description carries the full burden. It clearly describes the behavioral output: list datasets and return schema details including sample values and column categories. The verbs 'list' and 'get' suggest a read-only operation, so no mutation traits need to be disclosed. It doesn't mention any limitations (e.g., num of datasets), but for a simple discovery 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.

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

The description is a single, well-structured sentence with the action verb frontloaded ('List') followed by a colon and a precise bullet-like list of outputs. It contains no filler or repetition and every item adds useful detail.

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

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

The tool has no parameters and no output schema, so the description must fully explain what an agent will get from invoking it. It does so specifically: column names, dtypes, sample values, and categorised column list. There is nothing critical missing for correct invocation and interpretation of results.

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

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

The tool has 0 parameters, so there is no parameter space for the description to clarify. The baseline for parameterless tools is 4, and the description appropriately focuses on behavior rather than param references, which are absent.

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

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

The description uses a specific verb ('List') and a clear resource ('available datasets'), then enumerates exactly what is returned (schemas, column names, dtypes, sample values, categorised columns). This cleanly distinguishes it from the sibling chart/report/summary tools, which are all about producing outputs from datasets rather than discovering them.

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

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

The usage context is implied rather than explicit: it's a discovery/inspection tool, and the sibling names make it easy to infer when to use it (before charting or summarising). However, the description does not state when to use it over alternatives, nor mention that it is a prerequisite for the other tools.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It discloses that the tool POSTs to a fake API, converts HTML to PDF, and returns a JSON string with specific keys. This gives agents a clear model of side effects and expected outcome, though it does not cover error cases or potential side effects beyond the POST.

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

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

The description is compact, well organized with Args and Returns sections, and front-loads the core purpose in the first sentence. Every sentence contributes useful information with no fluff or repetition.

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

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

Given the tool's simplicity, the description covers the main inputs, the action, and the return format. It also ties html_path to a sibling tool, providing end-to-end context. It stops short of listing error conditions or edge cases, but for this tool that is not a significant gap.

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

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

Schema description coverage is 0%, but the description compensates by explaining both parameters. html_path is described as the output of build_html_report, and report_name is described as a logical name used in the API call. This adds meaning beyond the raw schema, although it could mention the default value or allowed formats more explicitly.

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

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

The description clearly states a specific action: converting an HTML report to PDF and posting it to the API. It also names the expected input, output, and even the return format, making the tool's purpose unmistakable. This differentiates it from sibling tools like build_html_report and chart generators.

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

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

The description provides clear usage context by stating that html_path should be the output of build_html_report, which signals the appropriate place in a workflow. It does not explicitly discuss when not to use the tool or compare it to alternatives, but the prerequisite guidance is strong enough for most agents.

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

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

No annotations are present, so the description carries the full behavioral burden. It discloses the default aggregation ('sum by default'), auto-generated filename behavior, and exact return format ('JSON str with chart_path and chart_data'). It does not mention filesystem side effects or dataset prerequisites, but these omissions are minor for a chart-generation tool.

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

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

The docstring is tightly structured with a one-line summary, grouped Args, and a Returns section. Every line contributes needed information, and there is no redundant or vague prose.

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

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

For a 6-parameter tool with no annotations, the description is nearly self-sufficient: it covers all parameters, defaults, optional behavior, and the output format. It lacks guidance on selecting this tool among siblings and explicit error/prerequisite conditions, which prevents a perfect score.

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

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

Schema description coverage is 0%, and the description compensates fully. Each parameter is explained with type constraints (categorical/date for x_column, numeric for y_column), defaults (sum aggregation, auto-generated filename), and optionality (group_by). This adds meaningful semantics beyond the raw schema.

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

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

The description states a specific verb ('Generate') and resource ('bar chart') and defines the source as a dataset column. The x_column/y_column parameter explanations clarify the categorical vs numeric mapping, which distinguishes it from sibling chart generators such as pie, histogram, line, and scatter.

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

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

No explicit when-to-use or alternative-selection guidance is provided. The name and parameters imply it is for comparing categorical or date categories against a numeric aggregate, but the description never tells an agent when to choose this over generate_pie_chart, generate_histogram, or generate_line_chart.

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

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

With no annotations, the description carries the behavioral burden; it discloses the JSON return shape and filename auto-generation. It does not state whether an existing file is overwritten, whether charts are persisted to disk as a side effect, or what error behavior occurs for non-numeric columns, though filename and chart_path imply file output.

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

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

The description is front-loaded with the core purpose and uses a compact Args/Returns structure where every line contributes parameter or output information. There is no filler or repetition.

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

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

For a five-parameter plotting tool, the description covers every parameter and the return shape, which is sufficient for calling it. It is slightly incomplete on higher-level context such as prerequisites (dataset must exist) and sibling selection, but the output schema signal and parameter coverage reduce the impact of that gap.

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

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

Schema description coverage is 0%, but the Args section gives meaningful semantic descriptions for all five parameters, including that column must be numeric, the bins default, and the filename auto-generation behavior. This fully compensates for the absence of schema descriptions.

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

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

The first sentence clearly states the action (generate), the artifact (histogram), and the input condition (numeric column), which inherently differentiates it from pie/bar/line/scatter siblings. The chart type and numeric qualifier leave no ambiguity about 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.

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

The numeric-column/distribution phrasing implies this tool is for inspecting continuous numeric distributions, but there is no explicit guidance about when to prefer it over generate_bar_chart, generate_line_chart, or generate_scatter_plot, and no mention of needing a dataset discovery step such as discover_datasets.

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

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

With no annotations provided, the description carries full burden of behavioral disclosure. It explains that y_column values are 'summed per X value', that group_by draws one line per group, and that filename is auto-generated if empty. It also specifies the return format as a JSON string with chart_path and chart_data. These are meaningful behavioral traits beyond what the schema states, though it does not discuss error handling or 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.

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

The description is organized as a docstring with a one-line purpose statement followed by a labeled Args section and a Returns section. It is concise with no fluff—every sentence provides functional information. The structure is clean and front-loaded, making key parameters easy to scan.

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

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

The description covers all six parameters, their roles, return format, and grouping behavior. Since an output schema is provided (the JSON structure), the description need not explain return values further. It adequately addresses the tool's complexity for an agent to invoke it correctly, including how y values are aggregated and how group_by affects rendering.

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

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

Schema description coverage is 0%, so the description fully compensates. Each parameter gets a meaningful explanation: dataset is a name, x_column is 'ideally a date or ordered category', y_column is 'numeric' and 'summed per X value', group_by is 'optional column to draw one line per group', and filename has auto-generation behavior. This adds substantial semantic value over the bare schema.

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

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

The description states a clear verb and resource: 'Generate a line chart'. It also cites the primary use case ('great for time series or trends'), which differentiates it from sibling chart tools like pie or scatter plots. The verb-resource combination is 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.

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

The description gives clear context on when to use the tool ('great for time series or trends'), which implies the appropriate scenario. However, it does not explicitly name alternatives or state when not to use it. No exclusions or trade-offs are discussed, 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.

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

With no annotations provided, the description carries the behavioral disclosure burden. It explains that category values become slices, value_column is summed per category, filename can be auto-generated, and the result is a JSON with chart_path and chart_data. This provides meaningful behavioral detail beyond the tool name and schema.

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

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

The description is concise and well-organized, with purpose first followed by a compact Args section and a Returns line. Each sentence contributes useful information and there is no repetition of schema content.

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

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

The description covers the core purpose, every parameter, and the return structure, which is enough for a straightforward chart-generation tool. It stops short of covering edge cases like file overwriting, path specifics, or validation behavior, but those are not essential for initial correct invocation.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining all five parameters: dataset, category_column, value_column, title, and filename. It clarifies that value_column is numeric and summed per category, and that filename is auto-generated when empty.

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

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

The opening sentence names a specific verb and resource pair: generate a pie chart from a categorical column. It also indicates the analytical purpose—showing composition—which clearly differentiates it from sibling chart tools like generate_histogram or generate_scatter_plot.

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

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

The description gives clear usage context: use this when the composition of a categorical column is needed, with a numeric column aggregated per category. It does not explicitly name alternatives or exclusions, but the purpose is specific enough to guide tool selection.

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

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

With no annotations provided, the description must disclose behavioral traits on its own. It does reveal the return format (JSON with chart_path and chart_data) and implies file output via the 'filename' parameter default behavior. However, it does not explicitly state whether the tool modifies any data, requires specific data types beyond 'numeric,' or has side effects like overwriting files. This is a moderate disclosure level 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.

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

The description is well-structured with a clear opening sentence for purpose and usage, followed by a compact parameter list and a returns line. It is concise without unnecessary detail, and the most important information (purpose and trigger) is front-loaded. A minor improvement could be trimming the parameter documentation if it were already in the schema, but it is not, so the structure is appropriate.

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

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

The description covers the core elements: purpose, usage trigger, all parameters, and the return format. Given the tool's moderate complexity (6 parameters, no nested objects) and the presence of an output schema, this is largely sufficient. The only gaps are explicit error handling or exception cases, which are not critical 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.

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

The schema provides no descriptions for the parameters, but the tool description includes a detailed Args section that explains each parameter's purpose (dataset, x_column, y_column, title, color_by, filename). This adds significant semantic value beyond the schema, fully compensating for the 0% schema description coverage.

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

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

The description clearly states the tool generates a scatter plot comparing two numeric columns, which explicitly differentiates it from sibling chart tools like bar, line, pie, and histogram charts. The verb-resource pairing is precise and leaves no ambiguity about 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.

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

The description provides a specific trigger condition: 'Best used when get_summary_statistics reveals a notable correlation between two columns worth visualising.' This gives clear when-to-use guidance. However, it does not explicitly state when not to use it or name alternative chart types, so it falls slightly short of a perfect score by not excluding other scenarios.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses the return contract: a JSON string with 'describe' and 'correlation' keys, per-column stats, and Pearson correlation. Edge cases like missing datasets or non-numeric columns are not mentioned, but the core behavior is clear.

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

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

The description is compact and well-structured with Args/Returns sections. The purpose and usage guidance are front-loaded, and every sentence contributes meaning without filler or redundancy.

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

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

For a one-parameter read-only tool with an output schema, the description covers purpose, timing, parameter semantics, and return shape. It lacks only minor details such as the source of valid dataset names and error behavior, but nothing essential is missing.

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

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

Schema description coverage is 0%, and the description's Args section supplies the only meaning: dataset is 'Name of the dataset.' This is minimally adequate for a single required string parameter, but it does not explain where to find dataset names or the expected format.

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

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

The description opens with a specific verb ('Return') and resource ('descriptive statistics and a correlation matrix for a dataset'). It distinguishes this tool from sibling chart generators by positioning it as a pre-chart analysis step.

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

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

The description explicitly states when to call this tool: 'Call this before generating charts to understand distributions, spot outliers, and find which numeric columns correlate strongly.' It gives clear context and intent, though it does not explicitly name alternatives or provide when-not-to-use conditions.

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