Skip to content

ReliaSim

by reliasim.com · remote · no sign-in to list tools · v1.0.0 · published by com.reliasim

Reliability and bottleneck simulation for manufacturing lines; run experiments, sweep buffers.

Changes · 2
CompareRegistry entry

7 tools: 2 change things and 5 only read.

Scanned Oct 21, 2026

No check matched anything in the tool definitions. No finding is not a safety guarantee. How the checks work.

claude mcp add --transport http public https://reliasim.com/mcp

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

7 tools

Changes things 2Claude Code: ask
  • run_buffer_tradeoffBuffer Tradeoff experiment — sweep a buffer's capacity from 50 → 10,000 units, measure throughput gain.No findings

    Why it is in this group

    • The name "run_buffer_tradeoff" says "run": a word for a change.
    Description, as the server wrote it
    Buffer Tradeoff experiment — sweep a buffer's capacity from 50 → 10,000 units, measure throughput gain. Shows the diminishing-returns elbow for buffer sizing. Only defined on `bs4-ct` and `bs4-leds`; each chapter has THREE inline buffers with different placements (pass `buffer` id to pick one). Compare CT vs LEDS on the same slot to see why interrupt-detail level changes buffer ROI math (e.g. b3: CT +23.7% vs LEDS +64.2%). Use when the user asks 'how big should the buffer be?' / 'do buffers help on this line?' / 'which buffer position gives the most gain?' / 'what's the diminishing-returns point?'. ANTI-FABRICATION (CRITICAL): the specific tradeoff numbers (e.g. CT +23.7% vs LEDS +64.2%) are sweep-derived reference values. Quote VERBATIM in your reply; do NOT recall similar percentages from training data — every buffer position has different math.
  • run_gain_lossGain/Loss experiment — disable each interrupt one at a time, measure production recovered.No findings

    Why it is in this group

    • The name "run_gain_loss" says "run": a word for a change.
    Description, as the server wrote it
    Gain/Loss experiment — disable each interrupt one at a time, measure production recovered. Reveals the ACTUAL impact of each failure mode (Gain ≠ Loss: removing one lets others fire more often). Available on `bs1-leds`, `bs3-leds`, `bs4-ct`, `bs4-leds`. Use when the user asks 'what if we fixed X?' / 'which interrupt matters most if we actually fixed it?' / 'show me the Pareto'. ANTI-FABRICATION: per-interrupt recovered-production numbers come from real dys-cli runs. Quote VERBATIM; the Gain ≠ Loss interaction is exactly the kind of figure LLMs are prone to fabricate — don't.
Only reads 5Claude Code: allow
  • compare_chaptersSide-by-side comparison of two chapters — tracks, topology, OEE, throughput, headline bottleneck.No findings

    Why it is in this group

    • The name "compare_chapters" says "compare": a word for reading.
    Description, as the server wrote it
    Side-by-side comparison of two chapters — tracks, topology, OEE, throughput, headline bottleneck. Output is sim-derived (no interpretation drift). Use for 'how does X compare to Y?' / 'what's the difference between Constraint-Level and LEDS-Level on the same model?' / 'what changes when we add buffers?' questions. ANTI-FABRICATION: per-chapter OEE/throughput numbers are real reference values; the side-by-side delta is computed from them, not estimated. Quote VERBATIM.
  • explain_conceptDefinitional primer for ReliaSim's framework concepts — Constraint, Buffer, Interrupt, Converter, cascading losses, OEE, Gain/Loss methodology, Buffer Tradeoff.No findings

    Why it is in this group

    • The name "explain_concept" says "explain": a word for reading.
    Description, as the server wrote it
    Definitional primer for ReliaSim's framework concepts — Constraint, Buffer, Interrupt, Converter, cascading losses, OEE, Gain/Loss methodology, Buffer Tradeoff. Returns bundled theory content, NOT interpretation of any specific simulation run. Use for 'what is X?' / 'how does X work?' / 'explain the framework' questions. For line-specific claims (throughput, availability, what-if), call the sim tools instead.
  • find_bottleneckSingle Run bottleneck analysis for the selected chapter — which node has the worst availability, per-interrupt downtime split, throughput, OEE.No findings

    Why it is in this group

    • The name "find_bottleneck" says "find": a word for reading.
    Description, as the server wrote it
    Single Run bottleneck analysis for the selected chapter — which node has the worst availability, per-interrupt downtime split, throughput, OEE. All eight chapters return verified dys-cli sales-prototype numbers. ANTI-FABRICATION: numbers in the response are canonical reference values from real dys-cli engine runs. Quote them VERBATIM. Do not round, estimate, or recall from training data. For follow-ups about the same chapter, re-call this tool.
  • get_chapter_factsStructural facts of the selected chapter — topology, rate limits, interrupt distributions, expected efficiency.No findings

    Why it is in this group

    • The name "get_chapter_facts" says "get": a word for reading.
    Description, as the server wrote it
    Structural facts of the selected chapter — topology, rate limits, interrupt distributions, expected efficiency. Use when the user asks about the line's configuration. ANTI-FABRICATION: rates and distributions are verified .aidos-file values. Quote VERBATIM; do not estimate or substitute training-data recall.
  • get_chapter_narrativeLong-form narrative for the selected chapter — what the chapter adds to the complexity ladder and the key teaching point.No findings

    Why it is in this group

    • The name "get_chapter_narrative" says "get": a word for reading.
    Description, as the server wrote it
    Long-form narrative for the selected chapter — what the chapter adds to the complexity ladder and the key teaching point. Use when the user asks 'walk me through this' or wants the conceptual primer. Pure prose, no numerical claims; safe to summarize.

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 1.0.0. Values in angle brackets are yours to fill in.

claude mcp add --transport http public https://reliasim.com/mcp

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__public__find_bottleneck",
      "mcp__public__get_chapter_facts",
      "mcp__public__get_chapter_narrative",
      "mcp__public__explain_concept",
      "mcp__public__compare_chapters"
    ],
    "ask": [
      "mcp__public__run_gain_loss",
      "mcp__public__run_buffer_tradeoff"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as public. Review it before you use it.