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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered and the description adds genuine behavioral detail beyond them: bootstrap reports progress and halts between batches on client cancellation, and with CUPED the arm means stay on the original scale while lift uses adjusted outcomes. That scale-semantics note is non-obvious and prevents misreading results. It does not mention error behavior when neither offer_id nor arrays are supplied.

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 purpose, then input modes, then behavioral caveats — a sensible order with no filler sentences. It is dense but every sentence carries information; a short lead-in labeling the CUPED sentences would improve scannability slightly.

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?

An output schema exists, so return values need not be explained, and the primary call pattern is covered. However, for a 13-parameter statistical tool with only 54% schema coverage, the description leaves the no-argument default path and the arm-label parameters unexplained, which an agent would need to select correctly.

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

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

Schema description coverage is 54% across 13 parameters, and the description compensates for some: offer_id vs control/treatment arrays, the CUPED covariate, and bootstrap ci_method. It says nothing about seed, bootstrap_iterations, alpha, outcome labels, or the control_arm/treatment_arm selectors, leaving several parameters meaningful only via their schema titles.

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

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

The opening sentence names a specific verb and output ('Estimate absolute and relative lift with a confidence interval'), which is unambiguous against siblings like power_calc or check_srm. It does not explicitly contrast itself with those siblings, so an agent must infer the boundary rather than being routed.

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 clearly states the two invocation modes: 'Pass offer_id to read the bundled synthetic exposures, or pass control and treatment arrays.' That is a real either/or routing instruction. It stops short of saying when to prefer this tool over power_calc or draft_readout, and gives no exclusion conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral facts: determinism ('the same salt and unit id always map to the same arm'), ordering ('arms are ordered by name'), and the explicit non-persistence guarantee. It stops short of covering output shape, but an output schema exists, so the remaining gap is minor.

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 the core action and mechanism, and no filler. The SHA-256 detail is arguably implementation-level, but it is what justifies the determinism claim, so it 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 read-only, three-parameter computation tool with full schema coverage and an output schema, the description covers purpose, determinism, ordering, and the non-write guarantee. Nothing an agent needs in order to invoke it correctly 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 coverage is 100%, so the baseline would be 3, but the description adds real meaning: it explains the stability contract between salt and unit id and clarifies that splits are matched against name-ordered arms. That ties the three parameters together in a way the schema alone does not.

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 ('Assign units to arms') plus the mechanism ('salted SHA-256 bucket'), which immediately separates it from siblings like check_srm, analyze_lift, or create_experiment. An agent can tell this is a deterministic assignment computation, not an experiment mutation.

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 negative guidance 'This does not write an experiment record' usefully implies this is a compute/preview step rather than a persistence step, but it never names an alternative or states the condition under which an agent should call this versus create_experiment or check_srm. Usage is only inferable, not spelled out.

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 openWorldHint=false, so safety is covered. The description adds genuine value with the caveat that a mismatch does not identify a cause, but says nothing about minimum sample size requirements or how borderline results near alpha should be interpreted.

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 zero waste; the operation is front-loaded and the interpretation caveat follows. Every sentence earns its place.

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

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

An output schema and full annotation coverage reduce the burden, but the description still lacks the when-to-use context and sample-size expectations an agent needs to decide whether to call this versus power_calc. Adequate, 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 100%, including the alpha default and its 'usual SRM bar' note, so the schema carries the parameter burden and baseline 3 applies. The description adds no meaning about counts or expected_weights beyond 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: a chi-square test of observed arm counts against intended weights. An agent can tell this apart from power_calc or analyze_lift. Minor gap: the tool name's abbreviation (SRM) is never expanded, so the domain term is only implied by 'A mismatch means...'.

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

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

Usage is implied by the statistical operation but there is no explicit when-to-use, no prerequisites, and no routing to siblings such as power_calc or assign_cells. The only guidance given is interpretive (a mismatch does not identify the cause), not procedural.

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, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: the elicitation form is client-dependent, and a failed/declined confirmation leaves the experiment open, meaning the call may be a no-op rather than a partial mutation.

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

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

The confirmation contract is front-loaded in the first sentence and the fallback path follows logically. The passive phrasing ("The confirmation form is elicited when the client supports it") is slightly indirect, but nothing is redundant or padded.

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 an output schema present, return values need no explanation, and the description fully covers the two-phase confirmation protocol an agent must understand to avoid a silent no-op. It omits whether closing is reversible and what permissions are needed, which are minor given destructiveHint is already set.

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 50%: the confirm parameter is documented in the schema, and the description reinforces its meaning (only true after a person has agreed) as the elicitation fallback. experiment_id carries no description anywhere, though its meaning is self-evident from the name, so this lands at the baseline.

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

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

The first sentence gives a specific verb and resource ("Mark an experiment closed") and adds the gating condition ("after the user confirms"). It is trivially separable from siblings such as create_experiment, list_experiments, and draft_readout without opening any 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?

The description clearly states when to call it (after user confirmation) and what to do when elicitation is unavailable (call again with confirm=true), plus a negative case (declining/cancelling does not close). It stops short of naming sibling alternatives, but for a terminal-state mutation the when/when-not guidance is explicit.

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-readonly, non-idempotent, non-destructive write. The description adds useful scope by clarifying that traffic assignment does not happen here, preventing an incorrect assumption, but it does not explain permissions, validation behavior, or what the traffic_split/salt fields do.

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 two sentences are tight and front-loaded, with no filler. It is appropriately brief, though that brevity comes at the cost of leaving important parameter and workflow context unexplained.

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?

Although an output schema and annotations reduce the need to explain return values and safety, the description is too thin for a seven-parameter write tool with 0% schema description coverage. It gives no help on required fields, optional configuration such as traffic_split or salt, or how this tool relates to the broader experiment workflow.

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% across seven parameters, and the description adds no meaning for name, hypothesis, primary_metric, salt, traffic_split, offer_id, or notes. This is the same failure mode as the low-calibration example where three parameters at 0% coverage scored a 1; here the gap is larger.

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 verb ('Store') and resource ('experiment'), and its caveat 'does not assign traffic by itself' helps separate it from assign_cells. It is clear enough to identify the tool, though 'running experiment' is slightly vague about whether it is creating a new record or persisting an existing one.

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 only usage-related information is the negative constraint that it does not assign traffic, which hints that assignment is a separate step. There is no explicit guidance on when to use this versus list_experiments, close_experiment, or assign_cells, nor any prerequisite or sequencing guidance beyond that single caveat.

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 cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds genuinely useful behavioral context that structured fields cannot convey: output may come from client-side sampling or a deterministic template fallback, so results vary in nature across clients. It still does not say whether the LLM path is validated, whether failures fall back silently, or what quality/consistency differences to expect.

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, front-loaded with the primary action and followed by the fallback caveat. No filler, though the line breaks and stray indentation in the source make it slightly less tidy than it could be.

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

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

The tool is simple, one parameter, and an output schema exists so return values need not be explained. However, the nondeterministic-vs-template duality is the tool's defining behavioral trait and the description leaves it ambiguous whether the caller can detect which path was taken or how to force the deterministic 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?

A single required experiment_id with 0% schema description coverage; the description does not explain the identifier's form, where to obtain it, or whether it must reference an existing experiment. With only one, self-descriptively named parameter the gap is small, but the low coverage means the description should have compensated and does not.

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: 'summarize an experiment' producing a readout draft. None of the siblings (power_calc, analyze_lift, check_srm, list_experiments, create_experiment, close_experiment) overlap with summarization, so the purpose is distinguishable without opening schemas, though the description never explicitly contrasts itself with the analysis siblings an agent might otherwise reach for.

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 context is only implied: you call it to get a readout draft for an experiment. There is no statement of when to prefer this over analyze_lift or list_experiments, no preconditions (does the experiment need results first?), and no note on whether an experiment_id that doesn't exist is an error.

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 openWorldHint=false, and the mention of a local SQLite file merely restates that the data is local. The description doesn't disclose the default behavior when status is omitted, the ordering, whether results are paginated, or what an empty result means — behavioral traits the annotations don't cover.

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, front-loaded sentence with no filler or redundancy. It is efficient, though the brevity comes at the cost of the missing parameter and usage detail noted above.

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?

An output schema exists, so return-value explanation isn't required, and the tool is simple with one optional parameter. Still, for a listing tool the description should say what the default listing contains and how the status filter behaves, which it omits.

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 the burden for the single status parameter, but it never mentions status at all. It doesn't explain the running/closed enum values or that the null default returns all experiments, leaving the parameter's meaning undocumented in both places.

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 verb and resource: "List experiment records." The clause about the SQLite file adds scope, though it doesn't differentiate this tool from any sibling or note that the other siblings are mutation/analysis tools rather than other listers.

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 at all: nothing says to call this before close_experiment or draft_readout, and nothing indicates whether an unfiltered call returns everything. The agent must infer usage entirely from the name.

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 openWorldHint=false, so safety is covered. The description adds substantive behavior beyond that: equal allocation only, two-sided test, and an explicit list of what the normal approximation ignores (peeking, multiple metrics, finite-population correction). It does not describe output shape, but an output schema exists to carry 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?

Three short sentences, nothing redundant. The core purpose is front-loaded and the constraint and caveat follow in priority order.

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 statistical tool with an output schema, the description covers the solve-mode constraint and the modeling limitations that an agent must know to use results correctly. Return values need not be explained given the output schema, and the remaining parameter detail is carried by 86% schema coverage.

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%, so the per-parameter meanings are largely handled structurally and a baseline 3 applies. The description earns an extra point by stating a cross-parameter constraint the schema cannot express — exactly one of mde or n_per_arm must be supplied — which is the single most likely invocation error for this tool.

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

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

The description opens with a specific verb and resource: 'Estimate equal-allocation sample size or MDE for a two-sided test.' That tells an agent both what is computed and the two solve modes, which no sibling tool covers. It does not name or differentiate against siblings, but the purpose itself is unambiguous.

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

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

'Provide exactly one of mde or n_per_arm' is an explicit operational rule that selects the solve direction, and the caveat sentence tells the agent when the result is not valid (peeking, multiple metrics, finite-population correction). It stops short of naming an alternative approach for those excluded cases, so there is no full when-to-use-instead routing.

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