ReliaStats

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

Annotations already cover read-only/idempotent; description adds the exact formula, warns against MTBF/MTTF confusion, and instructs to quote verbatim, which is behavioral context beyond the structured flags. No contradiction found.

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 sentences, front-loaded with the formula and then rationale and usage. No redundant words.

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: two numeric inputs and a deterministic formula. The description provides the formula, usage conditions, and a caveat, making it fully self-contained despite no output schema.

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?

Both parameters are fully described in the schema (100% coverage), and the description only repeats the same-time-unit requirement, adding no new semantic detail. Baseline 3 is appropriate.

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

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

The description clearly states a specific computation: availability = MTBF/(MTBF+MTTR) given the two parameters. It also contrasts with sibling explanatory tools by emphasizing it's a dedicated calculation tool.

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 says 'Use whenever a user supplies an MTBF/MTTR pair and asks for availability', giving a clear trigger. It doesn't list alternatives but the sibling set is mostly explanatory, so it's distinct.

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 idempotentHint=true, so no contradiction. The description adds valuable sourcing transparency with the ANTI-FABRICATION clause, explicitly tying content to docs/paired-model-bottling-line.md and files on reliasim-site. It also describes the optional narrowing behavior, but doesn't discuss output size or edge cases, which is acceptable given the good annotation coverage.

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 action and uses a structured dash list to enumerate content. The ANTI-FABRICATION sentence adds trust, and the section mention is practical. Every clause earns its place with zero fluff.

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 documentation tool with one optional param and no output schema, the description covers return scope, section names, and data provenance. It doesn't specify the return formatting/encoding, but that is a minor gap given annotations and the straightforward nature of the tool. Sibling context suggests the tool's niche is clear.

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% – the 'section' parameter is fully documented with examples and default behavior. The tool description merely reiterates that the parameter narrows to one H2 section but adds no new semantic information beyond the schema, so baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Return') and clearly scopes the resource: the full worked-example doc for the bottling-line paired model. It enumerates the exact content (topology with 5 machines, two tracks, 4 build sequences, file-shape mapping, cross-MCP tool chain), which distinguishes it from generic reliability tools like list_paired_models or explain_weibull_shape.

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

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

The description implies usage context (any request needing the bottling-line paired model worked example) and even narrows scope via the optional 'section' parameter. However, it does not explicitly contrast with sibling tools or state when not to use it, so it stops short of full 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, idempotentHint, and non-destructiveness. The description adds an anti-fabrication statement and source reference (docs/reliability-theory.md), which is valuable context about how output is generated. No contradiction with annotations.

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 opens with a clear verb and resource, then lists topics in a structured colon-separated list. It also includes a concise anti-fabrication note. Slightly long but each item earns its place by clarifying 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?

For a no-input educational tool, the description covers the main topics, quality level, and source. It lacks explicit linkage to sibling tools, but the scope is sufficiently complete for an agent to know what to expect.

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

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

The tool has zero parameters, and the description explicitly notes 'No inputs.' With 0 params, the baseline is 4, and no further parameter explanation is needed. The schema also confirms this.

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 it returns a 'textbook-tier explainer' and enumerates specific advanced reliability topics (censored data, MLE, Goodness-of-Fit, etc.), distinguishing it from siblings like explain_reliability_basics and explain_distributions_for_reliability.

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 word 'advanced' implies usage for advanced reliability patterns, but it does not explicitly contrast with alternatives such as explain_reliability_basics or explain_pi_vs_ci_for_validation. No clear when-to-use or when-not-to-use guidance is given, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond this by including an 'ANTI-FABRICATION' note that the text is sourced from docs/reliability-theory.md and that the β-as-failure-mode interpretation is a practitioner framing to quote verbatim. This is useful sourcing and presentation guidance not present in the annotations.

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

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

The description is a single dense paragraph that efficiently combines purpose, content details, usage triggers, and sourcing constraints. Every sentence earns its place, but the text could be improved with structured formatting (e.g., bullets) for easier scannability.

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 0-parameter informational tool with no output schema and robust annotations, the description is complete: it fully specifies the content scope ('textbook-tier distribution zoology', β table, alternative distributions, heuristics), provides explicit usage triggers, and includes important sourcing-specific instructions. An agent has everything needed to correctly select and invoke the tool.

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

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

The tool has zero parameters and an empty input schema. The description explicitly reinforces this with 'No inputs.' Since there are no parameters to document, the baseline of 4 applies per the rubric.

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

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

The description clearly states the tool's action with a specific verb and resource: 'Return a textbook-tier distribution zoology for reliability work' and enumerates the exact topics (Weibull β table, alternative distributions, heuristics). It also provides explicit example user queries ('which distribution should I fit', 'what does Weibull β mean', 'when to use Lognormal') that distinguish it from sibling tools like explain_reliability_basics and interpret_weibull_shape.

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

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

The description gives clear usage context with the direct statement 'Use when a user asks...' and lists three concrete query examples. However, it does not explicitly state when not to use this tool or directly name alternative sibling tools, falling just short of the highest level of 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds critical behavioral context: the bands are fixed plotting conventions and are NOT recomputed from loaded data. This anti-fabrication note and the mention of the source document provide transparency that the agent needs to avoid misleading users.

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 three sentences with a clear structure: main purpose, usage triggers, and important behavioral caveat. It is appropriately sized—no fluff, but it includes essential details.

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 zero-parameter, read-only explainer tool with no output schema, the description is complete: it covers purpose, specific usage triggers, the critical 'fixed conventions' behavior, and the doc source. This provides everything an agent needs to select and invoke the tool correctly.

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

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

The tool has zero parameters, so the baseline of 4 applies. The description correctly focuses on purpose and usage rather than parameter details, and no additional parameter information is needed.

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

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

The description clearly states the tool returns the specific explainer for the validation scatter chart's reference lines, naming the exact colors and chart type. This distinguishes it from sibling explain tools (e.g., explain_reliability_basics) by focusing on the validation scatter context.

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 explicitly lists user queries that should trigger this tool ('what do the bands mean', 'why is my point outside the blue line', 'how do I read the validation scatter'), giving clear when-to-use guidance. It does not mention alternatives, but the specificity makes the intended usage unambiguous.

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, and non-destructive hints, but the description adds a crucial behavioral constraint: it must quote verbatim from docs/reliability-theory.md and must not paraphrase from training-data recall. This goes beyond the annotations and meaningfully shapes agent behavior.

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 three sentences that front-load the tool's function, then give usage triggers and an anti-fabrication note. It is compact, clear, and every sentence earns its place.

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

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

The tool has no output schema, but the description fully enumerates the content domains, provides a source reference, and explains when to use it. For a textual explainer, this is complete and leaves no significant gaps.

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

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

The input schema has zero parameters and the description explicitly states 'No inputs,' so there are no parameter semantics to explain. Per the rubric, a zero-parameter tool receives a baseline of 4.

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 ('Return a textbook-tier explainer of reliability fundamentals') and enumerates the exact topics covered (R(t)/F(t)/f(t)/h(t), MTBF/MTTF/MTTR, availability identity, bathtub curve, series/parallel). This clearly distinguishes it from siblings like explain_advanced_reliability_patterns and explain_distributions_for_reliability.

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

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

The description provides explicit trigger queries ('Use when a user asks...'), giving the agent concrete conditions for selection. However, it does not explicitly state when-not-to-use or name alternative tools, so it stops short of full guidance (which would merit 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, idempotentHint=true, and destructiveHint=false. The description adds valuable context: 'Pure-math + lookup, no engine call, fully deterministic' and includes an anti-fabrication instruction with exact closed-form formulas, going beyond the annotations to clarify deterministic behavior and prevent hallucination.

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 no more than needed: four sentences pack purpose, output elements, usage trigger, and anti-fabrication guidance. It is front-loaded with the core action and avoids redundant phrasing.

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 fully enumerates what the tool returns (regime, action, MTTF, B-life) and even provides the exact formulas for MTTF and B-life. Combined with rich parameter descriptions and clear annotations, the description gives an agent everything needed to invoke the tool correctly and interpret its result.

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%; both beta and eta have detailed descriptions already. The tool description adds interpretive context for beta (bathtub regimes) and ties eta to MTTF/B-life outputs, but these are are return semantics rather than parameter syntax or format details. Baseline 3 is appropriate given the schema covers the mechanics.

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+resource: 'Given a Weibull shape parameter β ... return a plain-language interpretation' and enumerates the exact outputs (bathtub-curve regime, suggested action, MTTF/B-life). It clearly differentiates from siblings by focusing on interpreting β into actionable guidance, and explicitly states it is a pure-math lookup with no engine call.

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

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

The description provides an explicit usage trigger: 'Use when a user reports a fitted β and wants to know what to DO with it.' It establishes clear context but does not name alternative tools or state when not to use it, so it stops short of a full when/when-not/alternatives treatment.

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. The description adds current catalog size ('Today: a single paired model'), return content (canonical IDs + routing metadata), and the anti-fabrication caveat about not actually running simulations.

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?

Five sentences, each adding distinct value: purpose, current state, returns, usage, and anti-fabrication. No fluff or repetition.

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

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

Despite no output schema, the description clearly states what is returned (canonical model IDs + cross-MCP routing metadata) and the current content. It includes usage guidance and the soft-reference caveat, making it sufficient for an agent.

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

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

The schema has zero parameters, so the description doesn't need to explain parameter usage. Baseline 4 applies; the description adds no parameter-related detail, which is acceptable.

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 'Return the catalog of paired models' — a specific verb and resource. It further clarifies the scope (dynamics + statistics sandboxes) and differentiates from siblings by emphasizing cross-MCP routing metadata.

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 explicitly states 'Use when a user asks about cross-MCP workflows, paired sandboxes, or the bottling-line example.' The anti-fabrication note adds a clear boundary: for actual simulations, call ReliaSim tools directly, effectively naming the alternative.

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?

Despite rich annotations (readOnly, idempotent, non-destructive), the description adds significant behavioral detail: the algorithm is deterministic substring matching against a curated dictionary, rationales are from 'ChiAha content', and the output is explicitly not a fit. This goes well beyond annotation hints.

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

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

The description is concise and well-structured, front-loading the main function and then covering algorithm, output caveats, and anti-fabrication in a logical flow. Every sentence adds value.

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 one parameter and no output schema, the description fully covers what the tool does, how it works, what to expect from the output, and important limitations. It is complete for a tool of this complexity.

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% with a detailed description of the 'symptoms' parameter, so the baseline is 3. The tool description adds extra examples and clarifies the substring-matching behavior, which enriches understanding 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?

The description clearly states the action ('return an ordered shortlist of distribution candidates') and the specific input (free-text symptom description). It distinguishes itself from sibling explanation tools by focusing on recommendation rather than conceptual explanation.

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

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

The description provides clear context: input symptom text yields distribution candidates, and the output should be treated as a starting point, not a fit. It mentions that actual fitting happens elsewhere, but doesn't explicitly list when NOT to use this tool or name alternative tools for other purposes.

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 description goes beyond annotations by providing exact formulas for series and parallel calculations, and it explicitly states 'ANTI-FABRICATION: exact closed-form. Quote verbatim.' This communicates that the tool performs deterministic, exact math and should not be approximated. The readOnlyHint and idempotentHint are consistent, so no contradiction exists.

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 efficient. Each sentence serves a purpose: defining inputs/output, giving formulas, citing use cases, explaining composition, and setting anti-fabrication expectations. No fluff or redundant restatement of schema fields.

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 calculator with rich schema and annotations, the description covers all necessary operational context: what it computes, how it computes it, when to use it, how to handle mixed structures, and that it returns an exact value. The lack of an output schema is mitigated by the explicit formula, which implies the return type is a numeric reliability.

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?

Even though the schema already fully describes parameters (100% coverage), the description adds mathematical meaning: series = product, parallel = 1 − product(1−Rᵢ). This clarifies how the 'components' and 'structure' are used in the calculation, and it reinforces that component order is irrelevant. This is meaningful semantic value beyond the schema's property descriptions.

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

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

The description opens with a clear, specific statement: 'Given per-component reliabilities and a structure (series or parallel), return the system reliability.' It ties directly to the tool's name and provides an unambiguous resource (reliability calculation). It further distinguishes itself from broader RBD tooling by positioning itself as a 'back-of-envelope' calculator, which sets expectations.

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?

Explicit guidance is given: 'Useful for back-of-envelope RBD calcs before reaching for full RBD tooling' states when to use it, while 'For mixed-structure systems (series with parallel sub-blocks), call this tool repeatedly on the sub-blocks' prescribes how to handle larger structures. This is a clear directive with a practical decomposition strategy.

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, but the description adds significant behavioral context: 'Pure-math, fully deterministic,' 'ANTI-FABRICATION: every number is an exact closed-form value,' and the instruction to quote verbatim. It also discloses the conditional behavior when evaluateAtT is provided, which is not visible in annotations. No contradictions with annotations.

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 three sentences and front-loaded with the core purpose and output list, followed by usage context and a crucial anti-fabrication warning. Every sentence earns its place; there is no redundant or filler content.

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

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

For a purely mathematical tool with no output schema, the description is exceptionally complete: it lists all summary statistics, the exact formula for MTTF, the conditional evaluation at time t, deterministic guarantees, and appropriate usage context. It covers everything an agent needs to decide when to call and what to expect.

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 input schema provides 100% coverage for all three parameters, but the description adds substantive meaning: it gives the MTTF formula, clarifies that characteristic life is simply η, and explains the optional evaluateAtT parameter triggers R(t), F(t), and h(t) outputs. This goes beyond the schema's individual parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Given Weibull two-parameter (β, η), return all the closed-form summary statistics,' enumerating exact outputs like MTTF, B10/B50/B90 life, and conditional R(t), F(t), h(t). This clearly distinguishes it from sibling tools like explain_distributions_for_reliability or interpret_weibull_shape, which are explanatory rather than computational.

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

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

The description provides explicit when-to-use guidance: 'Use when the user has a fit and wants the numbers downstream tools normally compute' and warns against an alternative action ('don't recompute these from training-data recall'). However, it does not name specific sibling tools for alternative use cases, so it stops short of fully explicit exclusion guidance.

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