databutler-stats

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, non-open-world), so the bar is low. The description nonetheless adds real behavioral information beyond them: priors are renormalised to sum to 1 and the return is normalised posteriors, which matters given there is no output schema. It omits degenerate-case behaviour (e.g. all-zero likelihoods/prior mass).

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 tight sentences with zero filler; the core operation and the normalisation rule are front-loaded before any 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?

For a single-parameter tool with no output schema, the description covers the input's meaning, the computation, and the returned normalised posteriors. Missing only edge-case/degenerate-input handling, which is a minor gap at this complexity level.

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 carry parameter meaning. It does explain the two required nested fields (prior, likelihood of observed evidence) and clarifies that priors need not sum to 1, but it ignores the optional 'name' field and gives no numeric constraints or accepted ranges.

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?

States a specific verb ('Discrete Bayesian update') and resource ('competing hypotheses each with a prior and likelihood'), and names the output ('normalised posteriors'). This is clearly distinct from the numeric siblings (descriptive_stats, linear_regression), though it never explicitly contrasts itself with hypothesis_test, which is the nearest neighbour.

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 implies the applicable situation ('given competing hypotheses each with a prior and the likelihood of the observed evidence'), so usage is inferable. However, it gives no explicit when-to-use/when-not guidance and never points to an alternative sibling for related inferential questions.

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?

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the statistical method used per mode (t-based vs Wilson) and the default confidence of 0.95, which an agent cannot infer from the schema since no defaults are declared there.

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 dense sentences with no filler, and the primary capability plus the kind selector are front-loaded. The heavy parenthetical nesting makes it slightly harder to parse than a fully linear phrasing would be, but nothing is redundant.

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?

No output schema exists, so the description should ideally state the return shape (lower/upper bounds, point estimate) and behavior on invalid or underspecified input. For a 7-parameter, zero-required-parameter calculator it is adequate but leaves the agent guessing about output and validation.

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?

With 7 parameters and 0% schema description coverage, the description carries the full burden and does map all of them to modes: data or n/mean/sd for means, successes/n for proportions, kind as selector, confidence with its default. It does not clarify what n means in proportion mode or that sd pairs only with mean, leaving minor ambiguity.

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?

States a specific verb and resource ('Confidence interval for a mean ... or a proportion'), and names the exact statistical methods (t-based, Wilson) plus the two input modes. It is clearly distinguishable from calculation siblings, though it never explicitly contrasts itself with hypothesis_test or distribution.

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?

Implied routing is present: kind = mean vs proportion plus the data-or-summary input forms tell the agent which parameters pair with which mode. There is no explicit when-to-use guidance, no exclusion against the sibling inference tools, and no statement of prerequisites or invalid combinations.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the concrete set of statistics produced, which is useful behavioral content absent an output schema, but says nothing about edge cases such as empty arrays, NaN handling, or minimum sample size.

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?

One dense sentence that front-loads the purpose and then lists the computed outputs. No filler, no repetition of the title, every clause 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?

With no output schema, the enumeration of returned statistics does the work of describing the return value, and the single input is characterized as a numeric array. Only minor gaps remain (empty/degenerate input behavior, units or precision), so it is nearly complete for a simple read-only tool.

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

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

Schema coverage is 0% and there is a single required parameter 'data', but the description's phrase 'for a numeric array' effectively conveys the parameter's type and expected content. This compensates for the missing schema description without adding any further constraints or format details.

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?

States a specific computation (summary statistics) on a specific resource (a numeric array) and enumerates exactly which statistics are returned. It does not explicitly contrast itself with siblings like distribution or confidence_interval, but the resource and output set are distinctive enough that an agent can identify it.

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?

There is no guidance on when to use this rather than the statistical siblings (distribution, confidence_interval, hypothesis_test). The description is purely a capability statement with no context, prerequisites, or alternatives named.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that mean & variance are returned (useful since there is no output schema) and how params map per distribution, but says nothing about pagination, error behavior, or return structure 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.

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

Two dense sentences, zero waste, front-loaded with the verb and resource before the per-distribution parameter mapping. Every clause 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 4-param tool with a nested object, no output schema, and safety annotations, the description covers families, operations, combinability, and param keys. It could note that only 'dist' is required and clarify the return shape beyond mean & variance, but is otherwise complete.

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?

With only 50% schema coverage, the description carries the key gap: it fully documents the otherwise-bare nested 'params' object, giving per-distribution keys (normal {mean,sd}, t {df}, chi2 {df}, binomial {n,p}, poisson {lambda}). The 'at' and 'p' meanings are already in the schema, so this adds strong but not exhaustive value.

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?

States a specific verb ('Evaluate') and resource ('probability distribution'), then enumerates the supported families and the exact operations (pdf/pmf, cdf, quantile). An agent can immediately distinguish this statistical-evaluation tool from siblings like bayes_update or 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?

Provides clear context for when the tool applies by spelling out the operations ('pdf/pmf and cdf at a value, and/or the quantile at a probability'), and the 'and/or' signals these can be combined. It does not name alternatives or state when another tool (e.g., hypothesis_test) is preferred, so it stops short of explicit routing.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds behavior beyond that: default tail=two-sided, default alpha=0.05, and that the result includes a plain-language interpretation with assumptions.

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 dense but front-loaded sentences where nearly every clause maps a test name to its arguments. It is efficient for 17 parameters, though the inline enumeration reads like a compressed spec rather than 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?

With no output schema, the description correctly states what comes back (statistic, p-value, interpretation). Assumptions handling is mentioned. The only real gap is documentation of the table argument's structure and error behavior.

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% across 17 parameters, so the description carries the load and does so well, mapping each test to its inputs (data/mu0, data1/data2, successes/n/p0, successes1/n1/successes2/n2, observed/expected, table). It stops short of specifying the shape of `table` for chi2-independence or when `expected` may be omitted in chi2-gof.

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?

States a specific verb+resource ('Run a significance test') and even names the outputs (statistic, p-value, plain-language interpretation). It does not explicitly position itself against siblings like confidence_interval or descriptive_stats, but the scope is unmistakable.

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

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

It tells the agent exactly how to select a variant by enumerating each value of `test` with its required argument set, plus the optional tail and alpha defaults. What it lacks is when to reach for this tool versus confidence_interval 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?

Annotations already declare this is a read-only, idempotent, non-destructive, closed-world computation, so the safety profile is covered. The description usefully adds what the operation produces (slope, intercept, r, r², SE, p-value, equation) in the absence of an output schema, but says nothing about failure modes or input constraints.

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 dense sentence, front-loaded with the method and then the returned statistics. Every clause carries information and there is no 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 a two-parameter statistical computation with full annotation coverage, the method and its outputs are adequately described. The only meaningful gap is input constraints and error behavior, which is a minor omission rather than a blocking one.

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 schema alone leaves both parameters as bare number arrays. The phrase 'of y on x' does assign the response/predictor roles, which is genuine added meaning, but the description omits the equal-length and numeric-array constraints the caller must satisfy.

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?

States a precise method and resource — 'Simple linear regression of y on x' — plus the exact quantities returned. An agent can identify it as the OLS fit tool without opening the schema, though it never references any sibling to sharpen the distinction from 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?

There is no when-to-use guidance, no mention of when an alternative sibling (e.g. confidence_interval, hypothesis_test) is preferable, and no preconditions such as equal-length x/y arrays or minimum sample size. Usage is only inferable from the tool name itself.

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