mcpbeat

ReliaSim MCP Server

com.reliasim/public
answering

ReliaSim is answering right now. Last checked moments ago. It exposes 8 tools.

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

The linked repository no longer exists on GitHub — it was deleted or made private.

Uptime history 41 hours of history
41 hours agonow
100.0%
Uptime 24h
92 of 92 checks
8
Tools
read from the server
333 ms
Response time
average over 24h
open, no key
Access
streamable-http

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 0 min ago.

run in your terminal
claude mcp add public --transport http https://reliasim.com/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "public": {
      "url": "https://reliasim.com/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.public]
url = "https://reliasim.com/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "public": {
      "url": "https://reliasim.com/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "public": {
      "url": "https://reliasim.com/mcp"
    }
  }
}

Available tools 8

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

chapter
get_chapter_facts
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_narrative
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.
bottleneck
find_bottleneck
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.
buffer
run_buffer_tradeoff
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.
compare
compare_chapters
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
explain_concept
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.
gain
run_gain_loss
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.
showcase
run_showcase
LIVE experiment — run a bottling-line demo against the real ReliaSim engine with parameters you choose, and get its verbatim run envelope (metadata, execution stats, metrics, details). This is the only tool that COMPUTES fresh output: dial `duration_days` (or buffer capacities on the bs4 demos) and see the real numbers for that exact configuration. IMPORTANT: a run_showcase result is NOT a verified reference number — it is live output for the parameters you passed. Label it as an experiment result, not a canonical figure, and don't blend it with the curated reference numbers. For the canonical, verified OEE/throughput/bottleneck values use find_bottleneck / run_gain_loss / run_buffer_tradeoff instead. Quote any figures verbatim; do not round, average, or derive.

Endpoints

URLTransportStateLatencyChecked
https://reliasim.com/mcp streamable-http answering 320 ms 0 min ago

ReliaSim — questions

Answers built from our own checks of this server.

What can ReliaSim do?
It exposes 8 tools, read directly from the server on our last check. Among them: compare_chapters, explain_concept, find_bottleneck, get_chapter_facts, get_chapter_narrative, run_buffer_tradeoff and 2 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is ReliaSim working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 92 of 92 checks got a reply (100.0%), average response time 333 ms. The bar chart above shows every period we have measured.
Is ReliaSim still maintained?
The linked repository no longer exists on GitHub — it was deleted or made private. We show this because it changes what you can expect: an unmaintained server may keep answering for months and then stop without warning.
How do I connect ReliaSim?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does ReliaSim need an API key?
No. ReliaSim completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 8 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is ReliaSim?
It answers our handshake in 333 ms on average, which is faster than 42% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.