ReliaStats
Server Details
Reliability statistics — Weibull/lognormal fitting, MTBF/MTTR, availability, system composition.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 11 of 11 tools scored.
Each tool targets a distinct aspect of reliability engineering: compute functions (compute_availability, system_reliability), interpretations (interpret_weibull_shape, weibull_summary), educational explainers (explain_*), and catalog references (describe_bottling_line, list_paired_models, recommend_distribution). No two tools have overlapping purposes.
Most tools use a verb_noun pattern (compute_, describe_, explain_, interpret_, list_, recommend_), but 'system_reliability' and 'weibull_summary' are noun phrases without a verb, breaking the pattern. The mixture of styles could confuse an agent expecting consistent naming.
With 11 tools, the server is well-scoped for a focused reliability engineering domain. It covers core computations, educational content, and model references without being overwhelming or underdeveloped.
The tool surface covers essential reliability calculations, distribution explanations, and cross-MCP workflows. Minor gap: no built-in distribution fitting tool (though recommend_distribution suggests candidates). Data import is handled externally, keeping the server focused.
Available Tools
11 toolscompute_availabilityARead-onlyIdempotentInspect
Given MTBF and MTTR (same time unit), return steady-state availability A = MTBF / (MTBF + MTTR). One-line closed-form, but worth a dedicated tool so LLMs don't fumble the identity (the most common mistake is conflating MTBF with MTTF and silently inflating availability by the MTTR). Use whenever a user supplies an MTBF/MTTR pair and asks for availability. ANTI-FABRICATION: exact closed-form. Quote verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| mtbf | Yes | Mean Time Between Failures (repairable system). Same time unit as MTTR. | |
| mttr | Yes | Mean Time To Repair. Same time unit as MTBF. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant value beyond annotations: explains it's a one-line closed-form, warns against common LLM mistakes (conflating MTBF with MTTF), and emphasizes the exact formula with 'ANTI-FABRICATION: exact closed-form. Quote verbatim.' Annotations (readOnlyHint, idempotentHint) are consistent and enhanced.
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 relatively concise with around 80 words. It front-loads the core purpose and formula. Could trim the rationale about LLM mistakes slightly, but overall it earns its space.
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 simple deterministic computation, the schema fully describes parameters, annotations cover side effects, and the description explains purpose, usage, and return value (the formula). No output schema is needed because the result is explicitly the formula 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% for both parameters, so baseline is 3. The description adds the 'same time unit' reminder but doesn't provide substantial additional semantics 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 verb 'compute' and resource 'availability', gives the exact formula, and distinguishes itself from sibling tools (which explain concepts or recommend distributions) by being a dedicated computation 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 states 'Use whenever a user supplies an MTBF/MTTR pair and asks for availability.' This provides clear context for when to invoke. However, it does not explicitly mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_bottling_lineARead-onlyIdempotentInspect
Return the full worked-example doc for the bottling-line paired model — topology (5 machines: Filler/Capper/Labeler/Case Packer/Palletizer, 100 bottles/min, Weibull(30,1) TTF + Weibull(5,1) downtime at the Constraint-Level rollup), the two tracks (CT rollup vs LEDS-Level drill-down to 36 named failure modes), the 4 build sequences (BS1 → BS4), the file-shape mapping between ReliaSim outputs and ReliaStats modes, and a worked cross-MCP tool chain. Optional 'section' parameter narrows to one H2 section. ANTI-FABRICATION: content is sourced from docs/paired-model-bottling-line.md; every claim references the .aidos files or ChapterRegistry.fs in reliasim-site.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional H2 section name from docs/paired-model-bottling-line.md to narrow the response. Examples: 'Topology — the line itself', 'The two tracks — Constraint-Level vs LEDS-Level', 'The four build sequences (BS1 → BS4)', 'File-shape mapping — which ReliaStats mode consumes what', 'The cross-MCP workflow — worked example'. Omit to return the full doc. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds that content is sourced from a specific file and references existing project files, preventing fabrication concerns. No contradictions.
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 somewhat long but packs necessary detail for a complex document tool. It front-loads the purpose and organizes content logically, though some redundancy with schema exists.
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 is a document retrieval with an optional parameter, the description fully explains what the response contains, including the various sections. No output schema is needed as the content is described in prose.
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 'section' parameter. The tool description adds context by referencing the source file and listing example section names, providing additional meaning 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 it returns the full worked-example doc for the bottling-line paired model, listing specific content like topology, tracks, build sequences, and cross-MCP workflow. This distinguishes it from sibling tools like list_paired_models or compute_availability.
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 explains the optional 'section' parameter to narrow the response and provides examples. While it does not explicitly state when to use this vs alternatives, the context makes it clear this is for retrieving a specific model document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_advanced_reliability_patternsARead-onlyIdempotentInspect
Return a textbook-tier explainer of advanced reliability patterns: censored data (right/left/interval — the rule not the exception), Maximum Likelihood Estimation, Goodness-of-Fit tests (Anderson-Darling favored over KS for tail-sensitive reliability work), the Confidence-Interval vs Prediction-Interval distinction that backs the Interrupt Validation scatter, accelerated life testing (Arrhenius / inverse power law / Coffin-Manson), and Bayesian reliability. No inputs. ANTI-FABRICATION: text is sourced from docs/reliability-theory.md.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is clearly a safe, read-only operation. The description adds valuable context by specifying 'No inputs' and stating the source ('docs/reliability-theory.md') and anti-fabrication guard. This transparency about output provenance goes beyond 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 very concise: three sentences covering purpose, topics, input requirement, and source. Every sentence adds distinct value without redundancy. The structure front-loads the primary function and uses a clear list for topics. No fluff or unnecessary 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?
Given the tool has no parameters and no output schema, the description is mostly complete. It specifies what topics are covered and where the content comes from. However, it does not hint at the output format (e.g., plain text, markdown, or structured JSON), though the tool name and sibling context suggest a textual output. A slight gap remains.
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 is empty with 100% schema coverage, so the description's explicit statement 'No inputs' clarifies there are no parameters to configure. This adds meaning beyond the schema, which simply shows no properties. The baseline of 3 is exceeded because the confirmation removes ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'textbook-tier explainer of advanced reliability patterns' and lists specific topics (censored data, MLE, etc.). This distinguishes it from sibling tools like explain_reliability_basics and explain_distributions_for_reliability, which cover more fundamental or specific distributions.
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 does not explicitly state when to use this tool versus alternatives. It implies usage for advanced pattern explanations, but lacks direct guidance on when to choose it over siblings like explain_pi_vs_ci_for_validation or list_paired_models. The lack of exclusion criteria or context-aware recommendations reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_distributions_for_reliabilityARead-onlyIdempotentInspect
Return a textbook-tier distribution zoology for reliability work: why Weibull is the default, the shape-parameter β table mapping β-ranges to physical failure modes (β<1 infant mortality, β=1 random, β>1 wearout), when to reach for Exponential / Lognormal / Normal / Gamma, and practitioner heuristics for picking a distribution. No inputs. Use when a user asks 'which distribution should I fit' / 'what does Weibull β mean' / 'when to use Lognormal'. ANTI-FABRICATION: text is sourced from docs/reliability-theory.md. The β-as-failure-mode interpretation is ChiAha's practitioner framing — quote verbatim; do not paraphrase.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and not destructive. The description adds value by stating 'No inputs' and including an anti-fabrication instruction to quote from a specific source, which clarifies output sourcing.
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 purpose, followed by usage examples and a sourcing note. Every sentence adds value, though the anti-fabrication instruction could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no inputs and no output schema, the description is fully complete: it explains what it outputs, when to use it, and provides a sourcing directive. No additional context is needed.
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 no parameters (0 params, schema coverage 100%). The description does not need to add parameter info, and the baseline for zero parameters is 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 clearly states that the tool returns a 'textbook-tier distribution zoology for reliability work' covering Weibull β, alternatives like Exponential/Lognormal, and heuristics. It is distinct from sibling tools like 'explain_reliability_basics' and 'interpret_weibull_shape' due to its focus on distribution selection.
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 lists example queries that trigger usage: 'which distribution should I fit', 'what does Weibull β mean', 'when to use Lognormal'. While it does not explicitly state when not to use, the examples provide clear guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_pi_vs_ci_for_validationARead-onlyIdempotentInspect
Return the specific explainer for the ReliaStats Interrupt Validation scatter chart's red y=x / blue 95% Prediction Interval / teal 99% Confidence Interval reference lines. Use when a user asks 'what do the bands mean' / 'why is my point outside the blue line' / 'how do I read the validation scatter'. The bands are FIXED plotting conventions — they are NOT recomputed from the loaded data; this is anti-fab by design. Text sourced from docs/reliability-theory.md (the 'Confidence intervals vs prediction intervals' sub-section of Advanced Reliability Patterns).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds crucial context: the bands are fixed plotting conventions, NOT recomputed from loaded data, and the text is sourced from a documentation file. This fully explains behavior beyond 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 with no wasted words. First sentence states output, second gives usage triggers, third explains behavior and source. Efficient and well-organized.
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 no parameters and no output schema, the description covers purpose, usage, behavior, and source. It does not specify the return format (e.g., plain text vs. HTML), but this is likely obvious. Complete enough for the tool's simplicity.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter details (unnecessary), but does mention the return type ('explainer'). With zero params, the baseline is 4, and the description provides sufficient context.
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 an explainer for specific reference lines (red y=x, blue 95% PI, teal 99% CI) on the ReliaStats Interrupt Validation scatter chart. It distinguishes from sibling explainer tools by naming the exact 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?
The description provides explicit user queries that trigger this tool ('what do the bands mean', 'why is my point outside the blue line', 'how do I read the validation scatter'). It lacks an explicit 'when not to use' or reference to alternatives, but the examples are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_reliability_basicsARead-onlyIdempotentInspect
Return a textbook-tier explainer of reliability fundamentals: the four reliability functions R(t)/F(t)/f(t)/h(t), MTBF vs MTTF vs MTTR, the availability identity A = MTBF/(MTBF+MTTR), the bathtub curve, and series/parallel system reliability. No inputs. Use when a user asks 'what is reliability theory' / 'explain MTBF' / 'how does availability work' / 'what's a hazard rate'. ANTI-FABRICATION: text is sourced from docs/reliability-theory.md (the canonical ChiAha reliability primer). Quote sections verbatim; do not paraphrase reliability theory from training-data recall.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds important behavioral context: the text is sourced from docs/reliability-theory.md and must be quoted verbatim without paraphrasing from training-data recall. This goes beyond the annotations to ensure correctness and avoid fabrication.
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 paragraph, but it is packed with useful information: topics covered, usage cues, and an anti-fabrication rule. While not overly verbose, it could be slightly more concise without losing value. It is front-loaded with purpose.
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 there are no parameters and no output schema, the description fully covers what the tool does, when to use it, and how it should behave (correctly quoting from source). Annotations confirm safety. The description is complete for its intended use case.
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 schema description coverage is 100% (since there are no parameters to describe). With 0 parameters, baseline is 4. The description does not need to add parameter information, and it implicitly confirms no inputs are required.
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 a textbook-tier explainer of reliability fundamentals, listing specific topics (R(t), F(t), f(t), h(t), MTBF, MTTF, MTTR, availability identity, bathtub curve, series/parallel reliability). It distinguishes from sibling tools by being the basic explainer, as opposed to advanced or distribution-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: when a user asks questions like 'what is reliability theory', 'explain MTBF', 'how does availability work', or 'what is a hazard rate'. It also provides anti-fabrication instructions, directing the agent to quote verbatim from a specific source document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
interpret_weibull_shapeARead-onlyIdempotentInspect
Given a Weibull shape parameter β (and optionally the characteristic-life parameter η), return a plain-language interpretation: which bathtub-curve regime β implies (infant mortality / random / wearout), what action that suggests (process-of-care / steady-state monitoring / maintenance scheduling), and — if η provided — closed-form MTTF and B-life numbers from the Weibull formulas. Pure-math + lookup, no engine call, fully deterministic. Use when a user reports a fitted β and wants to know what to DO with it. ANTI-FABRICATION: MTTF and B-life are exact closed-form values from the two-parameter Weibull (η · Γ(1+1/β) and η · (-ln(1-p))^(1/β)). Quote them verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| eta | No | Optional Weibull characteristic-life parameter η, in the same time units you care about (e.g. hours). When provided, the response includes MTTF + B-life numbers. | |
| beta | Yes | Weibull shape parameter β (dimensionless). Typical reliability range 0.3 – 8.0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool is 'Pure-math + lookup, no engine call, fully deterministic' and specifies the anti-fabrication directive to quote MTTF/B-life verbatim, providing transparency beyond 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 concise, front-loaded with purpose, and well-structured. Every sentence adds value: purpose, scope, usage guidance, and anti-fabrication note. No unnecessary 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?
Despite lacking an output schema, the description fully describes the return value: interpretation of regime, suggested actions, and optionally MTTF/B-life. Given the tool's simplicity and the annotations, this is 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% with clear parameter descriptions. The description adds context by noting typical beta range (0.3-8.0) and explaining that eta's units should match the time units of interest. This adds meaning beyond the schema's basic 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 clearly states the tool returns a plain-language interpretation of the Weibull shape parameter, including regime, actions, and optional MTTF/B-life. It distinguishes itself from sibling tools like 'explain_reliability_basics' by focusing on actionable interpretation of fitted parameters.
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 explicitly says 'Use when a user reports a fitted β and wants to know what to DO with it,' providing clear context for when to invoke this tool. It does not explicitly mention when not to use it or list alternative tools, but the guidance is sufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_paired_modelsARead-onlyIdempotentInspect
Return the catalog of paired models — concrete real-world systems that live in two ChiAha sandboxes simultaneously, one for dynamics (DES via ReliaSim) and one for statistics (distribution fitting + validation via ReliaStats). Today: a single paired model — the bottling line. Returns canonical model IDs + cross-MCP routing metadata (which ReliaSim chapter, which ReliaSim MCP tools, which ReliaStats mode consumes which file shape). Use when a user asks about cross-MCP workflows, paired sandboxes, or the bottling-line example. ANTI-FABRICATION: this is a soft-reference catalog — to actually run a simulation, the LLM client calls ReliaSim's MCP tools directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context that this is a 'soft-reference catalog' and includes an anti-fabrication note, plus details on return content (canonical model IDs, cross-MCP routing metadata). 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 is moderately long but well-structured, front-loading the purpose, then details, then usage guidelines. Every sentence adds value, but could be slightly more concise (e.g., 'today' is extraneous).
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 fully explains what the tool returns (catalog with model IDs and routing metadata) and its relationship to other tools. It covers the current state and usage context comprehensively.
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?
No parameters exist, so baseline is 4. The description does not need to add parameter information, and it correctly focuses on the tool's purpose and usage without mentioning parameters.
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 catalog of paired models, specifically mentioning the bottling line as an example. It distinguishes from sibling tools like 'describe_bottling_line' by focusing on listing available models rather than describing one in detail.
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 states when to use: 'when a user asks about cross-MCP workflows, paired sandboxes, or the bottling-line example.' Also provides clear exclusion: 'to actually run a simulation, the LLM client calls ReliaSim's MCP tools directly.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_distributionARead-onlyIdempotentInspect
Given a free-text symptom description (e.g. 'manufacturing burn-in', 'bearing wearout under variable load', 'cosmic-ray bit flips'), return an ordered shortlist of distribution candidates with a one-line rationale per recommendation. Keyword-matched against a curated dictionary; ALWAYS treat output as a starting point for fitting work, not a fit. The actual fitting happens in the ReliaStats sandbox (protected/app.html). ANTI-FABRICATION: rationales are written ChiAha content; the algorithm is a deterministic substring match. Quote verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| symptoms | Yes | Free-text description of the failure data or context — e.g. 'manufacturing burn-in', 'bearing wearout', 'cosmic-ray bit flips', 'multi-stage degradation'. Substring-matched against a keyword dictionary; returns an ordered shortlist with rationale. | bearing wearout |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description reveals the tool is deterministic substring match, rationales are from ChiAha content, and output is only a starting point. This adds critical behavioral context without contradicting 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 front-loaded with purpose and includes necessary warnings, but it is slightly verbose with phrases like 'ANTI-FABRICATION: rationales are written ChiAha content'. Could be trimmed slightly without losing essential info, but overall well-structured.
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 low complexity (single param, no output schema), the description adequately covers input (free-text symptom) and output (ordered shortlist with one-line rationale). It also contextualizes output as starting point. Slightly more detail on the format of the shortlist could improve completeness, but it's sufficient.
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 single parameter 'symptoms' has 100% schema description coverage, so baseline is 3. The description adds value by providing examples ('e.g. 'manufacturing burn-in'', etc.) and reinforcing usage context (starting point, substring matching), going beyond the schema's basic explanation.
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: given a free-text symptom description, return an ordered shortlist of distribution candidates with rationale. It specifies the method (keyword-matched, deterministic) and distinguishes it from sibling tools like explain_distributions_for_reliability, which are explanatory rather than recommender.
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 explicitly states when to use the tool (to get starting distribution candidates) and how to treat the output ('ALWAYS treat output as a starting point for fitting work, not a fit'). It also warns about anti-fabrication (rationales are ChiAha content, algorithm is deterministic substring match) and instructs to 'Quote verbatim'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
system_reliabilityARead-onlyIdempotentInspect
Given per-component reliabilities and a structure ('series' or 'parallel'), return the system reliability. Series = product (all must work). Parallel = 1 − product(1−Rᵢ) (at least one works). Useful for back-of-envelope RBD calcs before reaching for full RBD tooling. For mixed-structure systems (series with parallel sub-blocks), call this tool repeatedly on the sub-blocks. ANTI-FABRICATION: exact closed-form. Quote verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| structure | Yes | RBD structure: 'series' (all must work) or 'parallel' (at least one works). | series |
| components | Yes | Per-component reliabilities in [0, 1]. Order doesn't matter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value with the 'ANTI-FABRICATION: exact closed-form' note, ensuring the agent knows to quote the result verbatim. No contradictions.
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, well-structured with separate sections for purpose, formulas, usage guidance, and anti-fabrication. Every sentence is informative and 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?
Given the tool's simplicity and good schema/annotations, the description covers all necessary context: input constraints, formulas, usage for mixed structures, and behavioral notes. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for both parameters. The description reinforces parameter meanings, adds formulas for calculation, and clarifies that component order doesn't matter, providing additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: given reliabilities and a structure, return system reliability. It distinguishes itself from sibling tools by focusing on simple series/parallel calculations, not full RBD analysis or explanatory content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use for back-of-envelope calculations before full RBD tooling, and for mixed-structure systems, call repeatedly on sub-blocks. Explicitly tells when to use alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weibull_summaryARead-onlyIdempotentInspect
Given Weibull two-parameter (β, η), return all the closed-form summary statistics: MTTF (η·Γ(1+1/β)), B10 / B50 / B90 life, characteristic life (just η, surfaced explicitly), and — if evaluateAtT supplied — R(t), F(t), and hazard h(t) at that time. Pure-math, fully deterministic. Use when the user has a fit and wants the numbers downstream tools normally compute (don't recompute these from training-data recall — call this tool). ANTI-FABRICATION: every number is an exact closed-form value. Quote verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| eta | Yes | Weibull characteristic life η, in your chosen time unit. | |
| beta | Yes | Weibull shape parameter β (dimensionless). | |
| evaluateAtT | No | Optional time t (same unit as η) at which to also return reliability R(t), failure F(t), and hazard h(t). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds 'Pure-math, fully deterministic' and an anti-fabrication note, reinforcing that the tool is safe and exact. No contradictions.
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 two sentences, highly efficient. Front-loaded with purpose, followed by usage and anti-fabrication note. Every sentence adds value with no waste.
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 3-parameter deterministic tool with no output schema, the description covers all necessary context: what is returned, when to use, and how to treat the output. The anti-fabrication note addresses reliability concerns. Complete and sufficient.
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 baseline is 3. The description does not add new parameter-level meaning beyond what the schema already provides (e.g., unit for eta, dimensionless for beta). However, it links parameters to output values, which offers some additional context.
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 purpose: given Weibull two-parameter (β, η), return closed-form summary statistics including MTTF, B10/B50/B90 life, characteristic life, and conditional evaluations. The verb 'return' and resource 'closed-form summary statistics' are specific, and it distinguishes from siblings by focusing on post-fit number crunching.
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 states when to use ('when the user has a fit and wants the numbers downstream tools normally compute') and what not to do ('don't recompute these from training-data recall'). Provides an anti-fabrication directive, guiding the agent to trust the exact values. Brothers do not overlap, so no alternative needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!