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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavioral information: that the tool works in two directions (solve for n given mde, or solve for mde given n) and that it is a pre-experiment planning aid rather than an analysis of observed data. It does not state the statistical assumptions baked in (α, power defaults) beyond what the schema shows.

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?

Dense and front-loaded — the two solve-for modes come first, then the required baseline inputs, then the usage rule. It reads as telegraphic notes ("Conversion: baseline_rate. Continuous: baseline_sd") rather than prose, which costs a little clarity on first read but wastes no sentences.

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 13-parameter planning tool with no output schema, the description omits a key decision rule: only metric is required, so which of mde / n_per_variant / daily_traffic / baseline_* must be supplied is never stated, and the shape of the result (per-variant n, total, days) is only implied. Coverage is adequate to call it but leaves the agent to infer valid parameter combinations from the schema alone.

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 only 31% across 13 parameters, but the description compensates well for the important ones: it explains mde semantics, that n_per_variant and mde are the two alternative solve-for inputs, that daily_traffic drives the days estimate, and that baseline_mean is only needed for a relative mde with continuous metrics. It adds a cross-parameter dependency (relative mde + continuous ⇒ baseline_mean) that the schema does not encode. Unexplained: alpha, variants, mde_type, alternative and adjust_for_variants are left to the 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?

States a specific verb and resource ("Plan an A/B test") and immediately enumerates the two concrete outputs: visitors needed per variant for a given mde, and the smallest detectable lift for a given n_per_variant. It also names the metric branches (conversion vs continuous) and the derived days-needed output, so an agent knows exactly what it gets back without opening the schema.

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?

"Use in an exploration (planning a future test); a running hypothesis test sizes itself in step 4" gives an explicit when-to-use and a when-not-to-use. The exclusion is weaker than it could be because it refers to the alternative by workflow position ("step 4") rather than naming the sibling it competes with — most plausibly run_test and power_analysis — so the agent must infer the 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description adds workflow context (step 6, standalone mode) but says nothing about what output is produced, why idempotentHint is false, or what happens when supplied prevalence/sensitivity values are inconsistent — gaps that matter for a calculation 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?

Three compact sentences, front-loaded with the workflow position and the eligibility condition; the usage exclusion is placed last where it belongs. The middle sentence is telegraphic ('Give prevalence, sensitivity, specificity (0–1), or file + condition_column + test_column') but still parseable.

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 read-only, non-destructive calculation tool with no output schema and no required parameters, the description states both the computed quantity and the input options, plus the escape hatch to skip_step. It has no structured output contract to lean on, and the confirmation_token gating is only covered by the schema, but nothing essential to making a correct call 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 only 14%, so the description must carry the load — and it largely does, defining prevalence/sensitivity/specificity as 0–1 quantities and test_column/condition_column as 0/1 indicator columns, plus the two alternative call shapes. It does not explain whether the two modes can be mixed or which combinations are valid, which is why this is a 4 rather than a 5.

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 computation (what share of positive flags is real, i.e. PPV) for a defined class of problems (rare events: fraud, defects, diagnoses, churn), and ties itself to workflow position step 6. It is distinguishable from siblings, though the phrasing 'sanity-check' in the title is looser than the body text.

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

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

It states both when to use (rare-event questions, or standalone during exploration) and when not to (non-rare-event questions → use skip_step 6), naming the alternative tool explicitly. It also tells the agent which of two input modes to supply.

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 only say readOnly=false, destructive=false, idempotent=false, openWorld=false; the description adds real behaviour: gated on explicit user request, confirmation-based section selection, conditional hypothesis section, format defaults, and that save_to writes into the workspace. Gaps remain around `overwrite` (which can replace an existing file, a write hazard the annotations do not flag) and what the call returns before confirmation.

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

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

Front-loaded with the gating condition and scope in the first sentence, then parameter semantics, then content rules — every sentence carries information. The telegraphic fragments ('format html (default) or markdown; save_to writes a file in the workspace') are dense but slightly clipped rather than flowingly clear.

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 six parameters, no output schema, and sparse schema descriptions, the definition covers the main inputs and content rules but not the full two-phase flow it implies: the confirm → confirmation_token → build sequence is only hinted at, and `overwrite` behaviour plus what the built report looks like are unstated. Adequate to invoke correctly in the common path, incomplete for the file-overwrite path.

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 only 17% (just confirmation_token), so the description must carry the load and largely does: `include` = result ids with default 'current analysis', `format` = html default or markdown, `save_to` = writes a file to the workspace. `title` and `overwrite` are left undocumented, keeping it short of a 5.

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 ('Builds a report') plus the source scope ('from results created in this session'), which no sibling tool shares — the nearest neighbours (create_visualization, describe, job_status) do different things. It also disambiguates what the report contains (hypothesis write-up vs exploration), so an agent knows exactly what artifact this produces.

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?

Gives an explicit trigger condition: 'only when the user asks for one', which is exactly the gate an agent needs before calling a non-idempotent write tool. It also notes the user must confirm the sections. It doesn't name alternatives or state what to do when the user asks for a report with no prior results, but there are no competing report tools to route between.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, closedWorld), so the description need only add context. It does add which jobs are cancellable, but says nothing about what happens to partial results, whether cancelling a completed job errors, or what the call returns. There is mild tension between "Stops" and readOnlyHint=true, but the idempotent/non-destructive framing is consistent, so this reads as a control-plane action rather than a flagrant contradiction.

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 front-loaded sentence with no filler; the scope qualifier is attached directly to the action. Slightly too terse for a tool with real edge cases, but nothing is wasted.

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 control tool with no output schema and no parameter descriptions, the description leaves the agent guessing about the outcome: does cancelling discard results, does it return a final status, and how should an already-complete job be handled? The bare annotation set does not cover these, so the gaps are meaningful.

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 compensate for the undocumented job_id. It partially does by implying job_id is the identifier returned by the tool that answered STILL RUNNING, which is useful provenance, but it gives no format, validity, or error semantics for that parameter.

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 ("Stops a background job") plus a scope qualifier (only jobs started by a tool that answered STILL RUNNING). An agent can distinguish it from the read-only job_status sibling, though the description never names that sibling explicitly.

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 phrase "started by a tool that answered STILL RUNNING" gives a usable trigger condition for invocation, implying the job_id came from that prior response. However, there is no when-not guidance (e.g., job already finished), no mention of the job_status alternative for polling instead of cancelling, and no stated preconditions.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds real content beyond them by enumerating exactly which assumptions are tested, so the agent knows the scope of the check. It doesn't describe the failure signal or response shape, and the idempotentHint=false is left unexplained for what looks like a pure read.

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 the step number front-loaded so the agent immediately places it in the sequence, followed by the concrete check list and the remediation pointer. No filler and nothing redundant with the schema.

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 parameters and no output schema, the description is nearly complete: it says what is validated and what to do if validation fails. The remaining gap is the return shape — an agent can't tell whether it gets per-assumption pass/fail flags, statistics, or a single verdict — but everything needed to decide to call it is 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline applies. The description correctly implies all inputs come from prior workflow state rather than arguments.

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 ('Checks') and an enumerated set of resources: shape (skew, kurtosis, small samples), group sizes, outliers, expected counts, ANCOVA slope equality, missing values. It anchors itself in the workflow ('for the test fixed in step 1'), which clearly separates it from siblings like choose_test, state_hypotheses and run_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?

Explicitly positions the tool as step 2, downstream of step 1's test selection, so the 'when' is unambiguous. It also routes the agent on failure conditions by naming the alternative — 'revising the test now (state_hypotheses again) is principled' — though it doesn't state the prerequisite that a test must already be fixed or what to do on a pass.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that the computation targets 'the data in the plan', which tells the agent it depends on prior workflow state, but says nothing about what happens if the plan lacks the needed data. Oddly, idempotentHint=false sits unreconciled against a read-only metric computation, and the description does not clarify it.

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 short sentence that front-loads the named metrics with no filler. Minor redundancy: 'Step 3' is repeated from the title, so the first two words spend a little space restating structured metadata.

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 parameters and no output schema, the description is the only place an agent can learn what comes back, and it never says whether results are appended to the plan, returned inline, or persisted for build_report. The metric list is adequate for identification but leaves the output contract and failure behavior unspecified.

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 takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly does not waste words on phantom arguments and instead points at the implicit input source, 'the data in the plan'.

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 concrete resource (data in the plan) and enumerates the specific statistics produced: standard deviation, IQR, coefficient of variation, outliers and variance ratio. That is far more specific than 'analyze spread'. However, it never contrasts itself with nearby siblings such as describe, group_summary or correlation, so an agent must infer the boundary.

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?

'Step 3' plus the title 'Step 3: check spread' implies the tool belongs to an ordered workflow and should follow the earlier steps, which is real positional guidance. There is no explicit when-to-use/when-not statement and no named alternative for the case where the agent already has spread numbers from describe or group_summary.

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, non-destructive and closed-world, so the safety profile is covered. The description adds that the result includes assumptions to check, but with no output schema it does not state the shape of the recommendation (a single tool name? ranked options? rationale text?), leaving the return value under-specified.

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 sentences, both earning their place, with the purpose front-loaded and the routing rule second. No redundancy 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 a 7-parameter decision-aid with no output schema, the description omits how the recommendation is returned and under what conditions it declines to recommend. With read-only annotations already covering behavior and the schema covering params well, this is adequate but has clear gaps in explaining the response.

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 86% and the goal enum documents its tricky members (ab_test vs plan_ab_test), so the schema carries the semantic load. The description mentions none of the seven parameters and adds nothing beyond what the schema already explains. Baseline 3 applies.

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?

Names a specific verb and resource ('Recommends which test tool to run for a research question') and adds a second output ('with the assumptions to check'), which distinguishes it from sibling tools like run_test and check_assumptions. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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?

'Call this first when unsure' gives a concrete decision rule for invoking this routing tool before run_test or check_assumptions. It gives no guidance on when NOT to call it (e.g., when the test is already known), so an agent must infer that.

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 and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — a user confirmation step precedes the call — but says nothing about how the confirmation_token round-trip works, what a pending state returns, or how inputs are validated.

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 short sentences with no filler, and the quantity definition is front-loaded. The brevity is not padded, though it edges toward under-specification for an 8-parameter 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?

With 8 parameters, 38% schema coverage, no output schema, and two structurally different modes, the description should explain which inputs go together and what the response contains (interval bounds, point estimate, method). It does none of that, leaving the agent to guess at call shape.

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

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

Schema description coverage is only 38% of 8 parameters, and the description compensates almost nothing: it names 'column' but never explains the mutually exclusive input modes (column/values for a mean, successes/n for a proportion) that determine which parameters are required. The agent must infer the entire parameter relationship from an undocumented enum and four bare numeric/string fields.

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 and its two modes (CI for a mean, CI for a proportion), which is enough to distinguish it from siblings like check_spread or run_test at a glance. No explicit sibling differentiation is offered, and the parenthetical '(column the user asked about)' reads as an instruction to the agent rather than a scope statement.

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 user confirms the column first' is a workflow prerequisite, not usage guidance — it never says when to pick this over run_test, describe, or check_spread, nor what happens when the requested quantity is neither a mean nor a proportion. The only actionable hint is the implicit two-step confirm-then-call flow.

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, destructiveHint=false, openWorldHint=false, so the safety bar is low; the description still adds real value by disclosing that no p-value is returned and that a user confirmation step precedes execution. It does not say whether confirmation_token is mandatory or what happens if it is omitted.

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?

Three short sentences, front-loaded with what the tool computes, then the alternative, then the prerequisite. 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 10-param, no-output-schema analytical tool the description covers purpose and the confirm-first workflow but leaves the input source (arrays vs file) and duplicate column-name parameters unexplained, which is exactly the ambiguity an agent will hit when constructing a call.

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 10 parameters and only 30% schema coverage, the description carries the burden but does not: it never explains the x/y arrays versus file versus x_name/y_name versus x_column/y_column alternatives, nor what pearson vs spearman do. Only the method choice ('r or rho') and CI are loosely implied.

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 definition names a specific computation (strength/direction between two numeric columns) and enumerates the outputs: r or rho, CI, least-squares line. Its explicit exclusion of a p-value separates it cleanly from the significance-testing siblings.

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 gives a clear when-not ('WITHOUT a p-value') and routes significance testing to a hypothesis_test with test "correlation", plus notes the user must confirm the columns first. The one weakness is that no sibling tool is literally named hypothesis_test (the list has run_test/choose_test), so the redirect is slightly ambiguous.

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 only declare the safety profile (not read-only, non-destructive, non-idempotent); the description adds genuinely new behavior: a confirmation-token gate on the proposed choices and persistence of charts for later report building. It omits what happens on overwrite and what `file` refers to, keeping it below a 5.

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?

Dense but front-loaded: the chart-type-to-column mapping comes first, then the confirmation precondition, then persistence. Nearly every clause carries information, though the chart-type list makes it a heavy single paragraph that could be split for scanability.

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 11-parameter mutation tool with no output schema, the description covers the core selection and confirmation workflow well. However, `file` is required yet never explained, and `overwrite`, `bins`, and `title` have no guidance anywhere, leaving real gaps for 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 only 9%, so the description carries most of the burden — and it does, by mapping each chart type to its required columns (e.g. box_plot needs column + optional group_column; pie needs x_column categories with optional y_column sum). Still leaves `file`, `title`, `bins`, and `overwrite` unexplained.

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?

Opens with a specific verb+resource ('Creates a chart') and immediately enumerates the six supported chart types, making it clearly distinguishable from siblings like describe, group_summary, and build_report. An agent knows exactly what output this produces.

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?

States a clear precondition ('The user confirms the chart type and columns first') and a downstream relationship ('Charts are kept for build_report'), which tells the agent both when to call and what the result feeds into. It does not explicitly name an alternative tool for non-chart exploration, so not quite 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the important confirmation prerequisite ('The user confirms the columns first'), but it doesn't explain the confirmation_token flow, the idempotentHint=false behavior, or what happens if no confirmation is given.

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-loads the output list, followed by the scope and confirmation constraint. It is dense but every sentence carries information; a 5 is withheld only because the statistics list is somewhat mechanical.

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?

There is no output schema, and the description helpfully enumerates the statistics returned, which is good. But for a 7-parameter tool with multiple input modes and a confirmation-token workflow, it omits how those parameters interact, leaving an agent to infer behavior from sparse schema descriptions.

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 43% schema description coverage across 7 parameters, the description needs to compensate but largely doesn't. It maps 'column' and 'by group' to column and group_column, and mentions confidence intervals, but leaves the 'name', 'values', and 'file' input modes entirely unexplained – an agent cannot tell from the description that values can be supplied directly instead of a file/column.

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 set of outputs (n, mean, SD, median, quartiles, range, skewness, kurtosis, shape, CI) for a column, optionally by group, which is clearly a descriptive-statistics operation. It doesn't distinguish itself from close siblings like group_summary, check_spread, or confidence_interval, so it stops short of a 5.

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 implies the tool is for a column the user asked about and that the user must confirm columns first, which is useful workflow context. However, it never says when to use this instead of group_summary, check_spread, or confidence_interval, nor 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.

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

Beyond the readOnly/idempotent annotations, it discloses the method (Pearson r for numeric, correlation ratio η plus highest/lowest group for categorical), that output is descriptive with no p-values, and that it scales to files of any size. The confirmation-token prerequisite is left to the schema rather than restated, which is the only gap.

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

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

Front-loads the motivating question pattern, then the mechanics, then next steps — a logical flow with little waste. It is dense and slightly long for one paragraph, but nearly every clause carries information the agent needs.

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 still conveys what comes back (a ranking by association strength, group extremes for categoricals) and the confirmation workflow. It stops short of describing result shape or ordering/truncation behavior tied to `top`, which would have made it 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?

Schema coverage is 80%, so the baseline is 3; the description adds that `target` must be numeric and that `columns` defaults to 'every other column'. It does not clarify what `top` limits (the schema has no description for it either), which keeps it from a 5.

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 outcome: ranks every other column by strength of relation to a numeric target, with concrete example questions ('what drives revenue?'). It also implicitly separates itself from the sibling `correlation` by being a broad exploratory ranking over all columns rather than a single pairwise computation.

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?

Explicitly frames the when-to-use case (open analytics questions), names the follow-up alternatives (group_summary, correlation, charts, hypothesis test), and states the precondition that the user confirms the target and columns first. It also says to use it inside an explore analysis, giving the agent clear 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?

The annotations already declare this as a non-destructive, read-only, closed-world operation, so the description need not restate safety. It adds useful behavioral context: results are descriptive only, no p-values are produced, omitting value_column switches to row counts, and confirmation is required before execution.

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 operation and uses short follow-up sentences for key constraints. The first sentence is dense with examples and statistic names, but those examples earn their place by clarifying the tool's scope.

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 definition is adequate for the core grouped-summary use case, but for an 8-parameter tool with no output schema it omits some parameter-level details and does not describe the return shape or top-N behavior beyond a brief mention. The schema covers some gaps, such as file input and confirmation_token, but not all.

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 schema description coverage at 38%, the description does add meaning for the core parameters: group_column is the category, value_column is the numeric column, stats are the summary measures, and sorting/top N are mentioned. However, it does not clarify sort_by, descending, top limits/defaults, or file handling, leaving several parameters dependent on the 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 gives a clear verb-like operation and resource: grouped summary statistics over a numeric column by another category column. It distinguishes the tool from inferential siblings by stating 'Descriptive only, no p-values,' though it does not explicitly name alternatives such as describe or run_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 examples make the intended use cases concrete, and the 'Descriptive only, no p-values' line excludes inferential use cases. It also notes the workflow prerequisite that the user confirms the columns first, but it does not explicitly route the agent to named alternative 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds useful output behavior (a preview plus per-column stats), but it contradicts the schema on supported formats by listing JSON as a valid input when the file parameter explicitly excludes JSON/BSON - a misleading claim an agent could act on.

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 sentences with zero waste: the first front-loads what is returned, the second front-loads when to call it. Nothing redundant with title or schema.

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 carries the return-value burden by enumerating the reported statistics and the preview size. It is nearly complete for a one-parameter read-only tool; the only gap is the conflicting statement about supported file formats.

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?

Only one parameter, and the schema documents it at 100% coverage including attachment conventions (file://, @name, #file:), relative path resolution and large-file tolerance. The description adds no parameter semantics beyond the schema, so the baseline of 3 applies.

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 ('Lists the columns') plus what exactly is reported: types, missing values, ranges, category values and a 5-row preview. That distinguishes it from siblings like describe or group_summary, though it slightly misfires on scope by naming JSON as supported when the schema says JSON/BSON is not supported.

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?

Gives a concrete when-to-use: 'before running tests on a file so you pass correct column and group names', which ties it to run_test/choose_test in the sibling list. It offers no exclusions or alternatives for cases where a full profiling tool (describe) would be a better fit.

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 description's job is to add behavior beyond that, and it does: the wait is bounded by wait_seconds, and the return is either the original tool's result or a progress snapshot. It doesn't cover failure states or confirmation of what happens exactly at the wait boundary, so not a 5.

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 compact sentence, front-loaded with the trigger condition rather than burying it. The parenthetical 'the same result the tool would have returned' is slightly redundant but earns its place by clarifying equivalence.

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 only two parameters, no output schema, and annotations covering safety, the description supplies the remaining essentials: trigger, bounded wait, and dual return (result vs. progress). Explicit failure/timeout behavior would complete it, but nothing critical is missing for 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 must compensate. It explains wait_seconds as a wait bound ('waits up to wait_seconds'), which adds meaning over the schema's bare numeric bounds, but it says nothing about job_id's origin or format. Partial compensation merits the baseline 3.

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 concrete action: it 'waits up to wait_seconds for the background job, then returns its result ... or its progress so far.' That gives verb+resource+outcome. It doesn't differentiate itself from siblings like cancel_job or workflow_status, so it isn't a 5.

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 opening clause 'For a tool that answered STILL RUNNING' is an explicit trigger condition — a strong when-to-use signal. It lacks any when-not guidance (e.g., don't use after a job has already completed, use cancel_job to abort instead), which keeps it below 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?

The annotations declare readOnlyHint=true, but the description says it records the user's choice and that save_columns keeps columns on disk. Those are persistent state changes, which contradicts the read-only annotation.

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 dense but front-loaded with the critical trigger conditions. Every clause adds useful information about eligibility, choice semantics, caching, and the required follow-up call.

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 three-parameter tool with no output schema, it explains the trigger, the choice tradeoffs, the persistence option, and the next action. It does not describe what confirmation or return value the agent should expect, but the core call behavior is covered.

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 explains both enum values for choice in detail and explains the effect of save_columns; only the file parameter remains unexplained, though its name is fairly self-evident.

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 and resource: it records the user's choice for a specific large file. It also clearly distinguishes the tool from the original data-reading tool by tying its use to a prior 'LARGE FILE' response.

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 gives explicit preconditions: only after a tool answered LARGE FILE and only after asking the user. It also tells the agent the next step: call the original tool again.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally; the description adds what actually gets removed ('columns kept on disk'). It does not say whether cleared columns can be regenerated, whether confirmation is required, or what 'list' returns — meaningful gaps for a destructive op.

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 short sentences with the verb and resource front-loaded and a useful pointer to the related tool. The nested quoting around "list" and "clear" is slightly awkward but not wasteful.

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 destructive annotations present but no output schema, the description covers the mutation side adequately but leaves the read side underspecified — an agent can't tell what a 'list' returns or in what form. For a 2-parameter tool this is acceptable but not 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?

Schema description coverage is 0% and there are no property descriptions, so the description must carry the load. It does explain the enum meanings ('list'/'clear') and that scope can be all files or one file, which effectively documents the optional `file` parameter, but it never names `file` or says what it should contain (path? name?).

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 gives a specific resource ('columns kept on disk from large files') and two concrete operations ('list', 'clear'). It clearly distinguishes the resource from siblings and points back to the producing tool (large_file_plan save_columns), though it doesn't name a competing sibling to steer away from.

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

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

It states the two actions and their scope ('all, or one file'), which implies when each is used, but there is no explicit when-to-use/when-not guidance or prerequisite such as a required prior large_file_plan run. Usage is inferred rather than stated.

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, non-destructive, non-idempotent, and closed-world behavior. The description adds important behavioral context: it is a calculation tool that may require user input (smallest_effect) and offers a conventional fallback. Return values are not described, but for a read-only calculation tool with no output schema, this is a minor gap.

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 densely packed but front-loads the hypothesis-test case and then covers exploration. Every sentence contributes useful information, though a slightly more structured format (e.g., separating modes) could 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?

Given the tool's complexity (7 parameters, no output schema, annotations present), the description covers the two main modes and the most complex parameter (smallest_effect). It omits details on alpha, alternative, and return values, but these are either defaulted in the schema or inferable from the calculation context.

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 only 14% (only 'power' is described). The description compensates by explaining smallest_effect (Cohen's d, r, or p₁) and the use_conventional fallback, and it mentions effect_size, n_per_group, and power for exploration. However, alpha and alternative are not explained, leaving notable gaps.

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 what the tool does: compute power (hypothesis test) or plan sample size (exploration). It distinguishes two distinct modes of operation, though it does not name sibling tools like run_test or confidence_interval as alternatives.

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 provides explicit guidance for two scenarios: in a hypothesis test, ask the user for smallest_effect, and if unknown, pass use_conventional: true; in an exploration, supply two of effect_size, n_per_group, and power. No when-not-to-use guidance is given, 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is covered; the description adds the non-obvious behavioral fact that the call takes no inputs and instead recomputes from state confirmed in step 1, plus the exact result fields returned. It does not state what happens when prerequisites are missing (error vs empty result), which matters given idempotentHint=false.

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 sentences, front-loaded with the step number and the action, then the outputs and prerequisite. No filler and nothing that could be cut without losing information.

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 compensates by listing the returned fields, and it states the workflow prerequisite. What remains unstated is the failure behavior when steps 1–4 are incomplete and whether re-running alters state, both relevant to a computation marked non-idempotent.

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?

There are zero parameters, so the baseline is 4. The description usefully explains why: the call is driven entirely by the test, columns and hypotheses confirmed in step 1 rather than by arguments, which tells the agent not to look for input fields.

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 (runs) and resource (the test) plus the exact scope: 'exactly the test, columns and hypotheses the user confirmed in step 1.' That scope phrase implicitly separates it from choose_test and check_assumptions in the sibling list, which select or validate rather than execute. It also enumerates the outputs (statistic, p-value, effect size, CI, verdict), so an agent knows what comes back.

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?

'Requires steps 1–4' gives an explicit prerequisite and the 'Step 5' framing makes the position in the workflow unambiguous. It does not name alternatives or say what to do if prerequisites are unmet, so it stops short of full when/when-not guidance.

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 and destructiveHint=false, so safety is largely covered. The description adds one genuinely useful behavioral fact — the reason appears in the report — but does not say whether the skip persists, can be undone, or how it affects a running workflow, and there is a mild tension between 'skip' and readOnlyHint that is left unresolved.

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 sentence, no filler, with the hard constraint front-loaded before the secondary detail about the reason appearing in the report.

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 tool with no output schema, the essentials are there, but the agent cannot predict the outcome of the call (does it return a confirmation, change workflow_status, or require a running analysis?) and could use a note on the reason's expected length.

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 compensate, and it does: it labels the enum values (4 = power, 6 = base rates) and constrains the reason parameter as short and reported downstream. It still does not indicate a length limit or expected reason 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?

States a specific action (skip a step) with a concrete constraint (only steps 4 and 6) and names what those steps are (power, base rates). An agent can tell this apart from siblings like power_analysis or base_rate_check, though the description never says so explicitly.

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 exclusion is implicit: 'Only steps 4 and 6 can be skipped' tells the agent what is not allowed, but there is no statement of when skipping is appropriate versus running power_analysis or base_rate_check instead, nor any prerequisite about the workflow state.

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 and destructiveHint=false, so safety is covered; the description usefully adds the ordering constraint that it must be called first and that it returns steps. It does not mention the consequence of calling it repeatedly (idempotentHint=false implies each call starts a fresh analysis, potentially discarding prior workflow state), which is the one behavioral trait an agent most needs here.

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?

It is front-loaded with the imperative call rule, then mode discrimination, then return value, with no filler. The only waste is the partial duplication of the mode semantics that already appear in the schema, which makes the middle sentence heavy.

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 compensates by noting it 'returns the steps to follow', and it covers the required question/mode decisions fully. What is missing is the lifecycle context: what happens to an in-progress analysis if the tool is called again, and whether the returned steps must be passed to run_test, describe, or another sibling.

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 100%, so both required parameters are documented in the schema itself. The description's mode definitions ('caused by something', 'test a claim', 'describe, summarise, visualise, estimate or plan') add a little interpretive help beyond the enum descriptions, but the two texts largely overlap, so baseline 3 applies.

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 frames this as the mandatory entry point for every new question and states it returns the steps to follow, which distinguishes it from executable siblings like run_test or describe. However, it never states plainly what the tool does with the question (it classifies and routes into an analysis workflow), so the underlying action must be inferred from the mode rules.

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 gives a clear invocation rule ('call this first for every new question') plus explicit decision criteria for choosing between the two modes, and tells the agent to ask the user when ambiguous. It does not reference any sibling tools such as skip_step or workflow_status, so the agent gets no guidance on how this tool relates to the rest of the workflow after the initial call.

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 declare readOnlyHint=true and idempotentHint=false, and the description explains the non-idempotency concretely: re-calling revises the plan and restarts steps 2–6. It also discloses the confirmation_token trust flow (only after user confirmation). It does not describe the response payload beyond the token, leaving some behavioral opacity.

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

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

Front-loaded with the step number and the ordering constraint, followed by the per-test field map, which earns its length. The run of examples is dense but purposeful; the parenthetical field lists could be framed slightly more scannably.

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

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

With no output schema and a free-form nested parameter, the description carries most of the burden and does so well: it covers state fixing, confirmation, revision semantics and per-test fields. It stops short of describing what the returned plan/token looks like or what downstream steps expect, which is the remaining 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 coverage is only 50% with a free-form nested object, and the description compensates substantially by enumerating the test_arguments fields for t_test, anova, ab_test, chi_square and correlation. The enumeration is incomplete for z_test, ancova, manova, fisher_exact and binomial_test, so an agent using those tests still lacks field guidance.

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 workflow position ('Step 1 of a hypothesis test') and the concrete action: fixing the test, data selection, and H₀/H₁ before execution. This cleanly separates it from run_test (execution) and choose_test (selection) without needing the schemas.

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

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

It states a strong temporal constraint ('BEFORE looking at results'), a data-scope rule ('Only use columns the user asked about'), and the confirmation requirement for columns, groups, direction and α. It does not explicitly name alternatives such as choose_test or check_assumptions, so routing is implied by workflow position rather than stated.

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 what information is surfaced (step completion, saved results), which is useful, but does not describe the shape of those results or any caveats, which matters because there is no output 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?

It is a single front-loaded sentence with no wasted clauses, and it leads with the core capability. The parenthetical '(for the report)' is slightly ambiguous but does not hurt 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 no-parameter, read-only status tool with no output schema, the description should define the return contents more concretely. It names the categories (analysis, six steps, saved results) but not what a saved result contains or how step statuses are represented, leaving the agent to infer the return shape.

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

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

This tool takes zero parameters, so the baseline is 4. There are no parameters whose meaning the description needs to clarify.

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 ('Shows') and the exact content returned: current analysis, the six-step completion state, and saved results. This clearly distinguishes it from action-oriented siblings like run_test or start_analysis, though it does not explicitly contrast with job_status.

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 only implied by the name and the phrase 'current analysis'; there is no explicit guidance on when to call it (e.g., between steps, before build_report) or when to prefer job_status. No alternatives or exclusions are named.

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