databutler-stats

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

With no annotations, the description must disclose behavioral detail. It usefully states that priors are renormalised to sum to 1 and that posteriors are normalised. However, it leaves out edge-case behavior, constraints on prior/likelihood values, and the exact return structure.

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?

Two focused sentences with no filler. The primary action is front-loaded, and the renormalisation detail follows naturally. Every sentence earns its place.

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 is sufficient for understanding the basic calculation but lacks the output format, handling of degenerate inputs, and any restrictions on prior/likelihood values. Given no output schema and no annotations, these gaps make it incomplete for fully reliable 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 carries the burden. It explains that 'hypotheses' is a collection of competing hypotheses, each with a prior and likelihood, directly mapping to the required schema fields. It doesn't discuss the optional 'name' field, but the core semantics are clear and add value beyond 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 names a specific operation ('Discrete Bayesian update'), the resource (competing hypotheses with priors and likelihoods), and the output (normalised posteriors). This clearly differentiates it from the frequentist statistical siblings like confidence_interval and hypothesis_test.

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 for when the tool applies: when updating discrete hypotheses given priors and evidence likelihoods. It does not spell out exclusions or alternatives, but the framing is specific enough for an agent to make the right selection among the listed siblings.

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 openly discloses the statistical methods (t-based and Wilson), the two input modes (data vs. summary statistics), and the default confidence level (0.95). It stops short of describing edge cases, error behavior, or assumptions like normality, but the core behavioral choices are transparent.

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 dense sentence that front-loads the main purpose and then packs in the mode and parameter information. It is efficient but somewhat cryptic due to the heavy use of slashes and semicolons; a slight restructuring would improve readability.

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 7 parameters, no required fields, and no output schema, the description covers the essential modes and parameter roles but omits examples, return format, validation rules, and how parameters interact (e.g., whether data can be combined with mean). An agent can invoke it but may be uncertain about required parameter combinations.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It does so by grouping them: data or n/mean/sd for the mean, successes/n for the proportion, kind to select the mode, and confidence as the level. It maps the primary parameters clearly, though it does not spell out constraints like n > 1 or successes ≤ n.

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 specifies a clear purpose: computing a confidence interval for either a mean (t-based) or a proportion (Wilson). It distinguishes itself from sibling tools like hypothesis_test and descriptive_stats by naming its exact statistical output and method.

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?

Usage is implied: use when you need a confidence interval for a mean or proportion. However, there is no explicit guidance on when not to use it, no mention of alternatives, and no comparison to siblings such as hypothesis_test or bayes_update.

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 full burden of behavioral disclosure. It does list the statistics returned, which is useful, but it does not disclose edge-case behavior such as handling of empty arrays, NaN values, or missing data. The operation is inherently read-only and non-destructive, which is implicitly 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 a single, information-dense sentence with no wasted words. It front-loads the purpose and then lists the outputs in a clear, scannable manner. Every element contributes to understanding the tool.

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 is simple with one parameter and no output schema, and the description covers the primary output values. However, it omits input constraints and return structure, and does not address edge cases that are relevant for descriptive statistics. The description is adequate for basic selection but not fully complete for confident invocation in unusual cases.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameter. However, it only restates that the input is a numeric array, which adds little beyond the schema's array-of-numbers type. It does not clarify minimum length, whether missing values are allowed, or any constraints on the numeric values.

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 identifies the tool as computing summary statistics for a numeric array and names the exact outputs: mean, median, sd, variance, quartiles, IQR, skewness, min/max. This specific list distinguishes it from sibling tools like hypothesis_test or confidence_interval, which serve different statistical purposes.

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 no guidance on when to choose this tool over alternatives. It does not mention sibling tools, exclusions, or conditions for use. The intended use is implied by the name and output list, but no explicit when-to-use or when-not-to-use information is given.

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 disclosure burden. It clearly states which computations are available and which parameters each distribution expects, but it does not describe the return format, behavior when both 'at' and 'p' are supplied, or handling of invalid parameter values.

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 with the core purpose, followed by a dense but necessary per-distribution parameter reference. No redundant wording is present.

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 pure computation tool, the description covers the supported operations and all distribution-specific parameter schemas well, even without an output schema. It leaves minor gaps such as exact return shape and parameter value constraints, but the essentials for invoking the tool correctly are present.

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 only describes 'p' and 'at'; 'dist' has just an enum and 'params' is an untyped object. The description compensates by listing each distribution and its expected parameter keys, adding real meaning beyond the schema. It stops short of full specificity by omitting parameter types and constraints.

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 names the exact verb 'Evaluate' and the resource 'probability distribution', then enumerates the supported distributions and the computed quantities: pdf/pmf, cdf, quantile, mean, and variance. This is concrete enough to distinguish the tool from statistical siblings like hypothesis_test or linear_regression.

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 intended use is implied: call this when you need distribution-level calculations such as pdf, cdf, or quantile values. However, there is no explicit guidance about when not to use it or how it compares to sibling tools like confidence_interval or descriptive_stats.

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 behavioral burden and does disclose key behavior: the computed outputs, that interpretations come with assumptions, the optional tail direction, and the alpha default. It does not address edge cases like invalid inputs or missing data, 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.

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

The description is a single dense, front-loaded paragraph with no filler; it states the purpose first, then the test menu and defaults. The compact brace syntax is efficient but somewhat dense, requiring careful parsing to map each test to its parameters.

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 17-parameter tool with no output schema and no annotations, the description covers test selection, most parameter groupings, defaults, and expected return content. It is not exhaustive—invalid input handling and exact return structure are absent—but it provides enough for an agent to invoke the common cases 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?

Schema description coverage is 0%, so the description must compensate, and it substantially does by binding parameters to specific tests, e.g., one-sample-t {data, mu0}, one-proportion-z {successes, n, p0}, and chi2-independence {table}. The main gaps are the ambiguous 'expected?' optional marker and the unspecified structure of 'table', so a few parameters remain under-specified.

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 action ('Run a significance test') and clearly lists the outputs: statistic, p-value, and plain-language interpretation with assumptions. The enumerated test menu (one-sample-t, two-sample-t, one-proportion-z, etc.) makes the tool's scope unmistakable and distinguishes it from estimation or descriptive sibling tools.

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 practical selection guidance by mapping hypothesis scenarios to concrete test names, and documents defaults for tail and alpha. However, it never explicitly states when to prefer hypothesis_test over siblings like confidence_interval or descriptive_stats, nor does it provide when-not conditions.

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 behavioral burden. It discloses the computed outputs, which is useful, but omits behavioral details such as handling of mismatched array lengths, missing values, or whether the intercept is included. It implies a pure computation with no side effects but does not state it explicitly.

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?

A single compact sentence with no filler, front-loaded with the operation and followed by a list of outputs. Every word earns its place.

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 simple two-parameter regression tool without output schema or annotations, the description covers the core output contract. However, it leaves input constraints (equal-length arrays) and error behavior implicit, and does not cross-reference sibling tools. It is adequate but has clear gaps.

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 coverage is 0%, so the description must add meaning to the bare array parameters. It does clarify roles: 'of y on x' establishes y as dependent and x as independent. However, it does not specify that the arrays must be numeric, equal in length, or how empty arrays are handled.

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 statistical operation ('simple linear regression of y on x') and enumerates the outputs (slope, intercept, r, r², slope std error, p-value, equation). This clearly differentiates it from sibling tools like hypothesis_test or descriptive_stats.

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 intended use is implied by the phrase 'simple linear regression' — an agent can infer it is for bivariate linear relationships. However, it does not explicitly say when to prefer this over siblings, nor does it mention exclusions like multiple regression or prerequisites such as equal-length arrays.

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