Connect

8 clients · secrets stay placeholders

JSON (mcpServers)Claude CodeCodexOpenCodeCursorVS CodeGemini CLIGoose

{
  "mcpServers": {
    "public": {
      "type": "http",
      "url": "https://reliasim.com/mcp"
    }
  }
}

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

[mcp_servers.public]
url = "https://reliasim.com/mcp"

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "public": {
      "type": "remote",
      "url": "https://reliasim.com/mcp",
      "enabled": true
    }
  }
}

{
  "mcpServers": {
    "public": {
      "type": "http",
      "url": "https://reliasim.com/mcp"
    }
  },
  "deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=public&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vcmVsaWFzaW0uY29tL21jcCJ9"
}

{
  "servers": {
    "public": {
      "type": "http",
      "url": "https://reliasim.com/mcp"
    }
  }
}

{
  "mcpServers": {
    "public": {
      "httpUrl": "https://reliasim.com/mcp"
    }
  }
}

extensions:
  "public":
    enabled: true
    name: "public"
    type: streamable_http
    uri: "https://reliasim.com/mcp"
    timeout: 300

Quality 79 / 100good

protocol75 · weight 25

warn
protocol.modernnewest supported version is 2024-11-05; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
n/a
protocol.statelessonly applies to 2026-07-28 servers
pass
protocol.transportstreamable HTTP
n/a
protocol.list_ttlonly applies to 2026-07-28 servers

authorizationn/a · weight 15

n/a
auth.prm, auth.as_metadata, auth.cimdno remote uses OAuth
n/a
auth.secret_in_urlno templated URL

tool hygiene71 · weight 30

pass
tools.descriptionsevery tool has a description
pass
tools.description_lengthdescriptions are concise
pass
tools.schemasevery tool has an object input schema
fail
tools.annotationsno tool declares readOnlyHint or destructiveHint, so clients cannot tell safe calls from risky ones
fail
tools.directory_hintsno tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: find_bottleneck (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_chapter_narrative (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); run_gain_loss (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); …
pass
tools.token_costabout 1,933 tokens to load every tool
pass
tools.api_dumptools are not a one-to-one API dump

stability100 · weight 15

pass
stability.changesno tool changes in 30 days
pass
stability.rug_pullno tool changed its meaning under the same name

dependenciesn/a · weight 15

n/a
deps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI package

7 tools, about 1,933 tokens to load them all · tool set ba83b3612ba9 · checked 2026-10-20 10:03 UTC

Tool changes

No tool definition changes recorded. A server's first observation is its baseline; later probes record what changes.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.

Trust 86 / 100

provenance75

liveness100

freshness65

hygiene100

+repository +dns-namespace +reachable +uptime-100% ~updated-146d-ago

Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.

Endpoints

remote	auth	reachable	uptime 30d	p50	protocol	last ok
`https://reliasim.com/mcp` streamable-http	none	yes	100%	176 ms	2024-11-05	2026-10-20

Tools (7)

`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_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.
`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.
`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.
`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.
`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.

Schemas: list_tools.

Similar MCP servers

Official server.json

{
  "name": "com.reliasim/public",
  "icons": [
    {
      "src": "https://reliasim.com/favicon-192.png",
      "sizes": [
        "192x192"
      ],
      "mimeType": "image/png"
    }
  ],
  "title": "ReliaSim",
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "remotes": [
    {
      "url": "https://reliasim.com/mcp",
      "type": "streamable-http"
    }
  ],
  "version": "1.0.0",
  "repository": {
    "url": "https://github.com/chiaha-ai/reliasim-site",
    "source": "github"
  },
  "description": "Reliability and bottleneck simulation for manufacturing lines; run experiments, sweep buffers."
}