# QueueSim (remote · queuesim.com)

Run M/M/c queue simulations and four scenarios (call center, ER, coffee shop, single server).

- Trust score: 71/100 (medium)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `queuesim.com`: 71/100 (this document), [markdown](https://verifymcp.io/servers/com-queuesim-public/mcp-v1.md), [page](https://verifymcp.io/servers/com-queuesim-public/mcp-v1)

## Channel facts

- Endpoint: `https://queuesim.com/mcp/v1`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 80/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 64/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2977 tokens (~270/item across 11 items; 11 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 96/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 86% of tool parameters carry a description.
  - Structured output schemas are declared (73% of tools); any adoption earns full credit.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-queuesim-public https://queuesim.com/mcp/v1
```

### Codex

```toml
[mcp_servers.com-queuesim-public]
url = "https://queuesim.com/mcp/v1"
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add com-queuesim-public --url https://queuesim.com/mcp/v1 --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-queuesim-public:
    url: "https://queuesim.com/mcp/v1"
```

### Other

```json
{
  "mcpServers": {
    "com-queuesim-public": {
      "type": "http",
      "url": "https://queuesim.com/mcp/v1"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 70, +4)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 66, −1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-28 (score 67, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 66, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 65)

First indexed and scored.

## MCP tools (11)

### `simulate_mmc` (~435 tokens)

Run a generic M/M/c queue simulation. Provide an arrival rate (λ, arrivals/hour), a service rate per server (μ, customers/hour each server can finish), and a server count (c). Optional: distribution shapes, service coefficient of variation, run length. Returns per-hour metrics and an overall summary (avg wait, queue length, offered load, throughput). This is the primary tool for 'how many servers do I need?' / 'what's my average wait?' style questions. ALSO preferred over simulate_scenario for what-if questions about scheduled scenarios (Coffee Shop) when the user wants flat uniform numbers — pull the peak params from describe_scenario and run them here. That usually matches user intent better than collapsing a schedule. ANTI-FABRICATION: the returned numbers come from a real discrete-event simulation run. Quote them VERBATIM in your reply. Do not round, estimate, or compute derived figures from training-data recall. If the user asks a follow-up about the same configuration, re-call this tool rather than recalling numbers from earlier in the conversation.

Input parameters:

- `arrivalDistribution` (string): Shape of inter-arrival times. 'Exponential' = Poisson process (default). 'Constant' = evenly-spaced.
- `arrivalRate` (number, required): Mean arrivals per hour (λ). Any positive value up to 200.
- `servers` (integer, required): Number of parallel servers (c). Integer 1-50.
- `serviceCoV` (number): Coefficient of variation for service time — used when serviceDistribution is 'Normal' or 'LogNormal'. Ignored for Exponential/Constant. Range 0-5.
- `serviceDistribution` (string): Shape of service-time distribution. 'Exponential' = classical M/M/c (default).
- `serviceRate` (number, required): Mean customers one server can finish per hour (μ). Must be > 0.
- `simulationDays` (integer): Days to simulate (default 7). Range 1-30 — longer runs are not supported on the public surface; for production-scale studies contact queuesim@chiaha.com.

Output parameters:

- `hourly` (array)
- `inputs` (object): Echo of the run's parameters.
- `summary` (object)

### `list_scenarios` (~71 tokens)

List the four pre-built QueueSim scenarios. Returns key, title, and one-line description for each (Single Server, Coffee Shop, Grocery Checkout, Call Center). Call this when the user's problem matches one of the preset shapes — use describe_scenario for more detail and simulate_scenario to run one.

Output parameters:

- `scenarios` (array)

### `describe_scenario` (~66 tokens)

Return full details for one preset scenario: title, description, teaching note, peak parameters, and per-hour arrival + staffing arrays. Use this before simulate_scenario to understand the default shape and what overrides make sense.

Input parameters:

- `name` (string, required): Scenario key from list_scenarios.

Output parameters:

- `defaults` (object)
- `description` (string)
- `key` (string)
- `supportedOverrides` (array)
- `teachingNote` (string)
- `title` (string)

### `simulate_scenario` (~300 tokens)

Run one of the four preset scenarios (single, coffee, grocery, callcenter) with optional overrides. Overrides apply UNIFORMLY across open hours — e.g. setting servers=5 on 'coffee' replaces the 4/6/4 staffing pattern with a flat 5 during open hours (closed hours stay at zero). Use this for (a) faithful reproduction of a scenario's defaults, or (b) uniform scaling (everywhere it was open, use these new numbers). Do NOT use this when the user wants to keep a scheduled scenario's shape but tweak just one part — there's no per-hour override here, and collapsing a 4/6/4 pattern to 5 often isn't what the user meant. For flat what-if analysis on scheduled scenarios, prefer simulate_mmc using peak params from describe_scenario. ANTI-FABRICATION: returned numbers come from a real discrete-event simulation run. Quote them VERBATIM in your reply. Do not round, estimate, or compute derived figures from training-data recall. If the user asks a follow-up about the same scenario+overrides, re-call this tool rather than recalling numbers from earlier in the conversation.

Input parameters:

- `name` (string, required): Scenario key from list_scenarios.
- `overrides` (object): Optional overrides applied uniformly across open hours (closed hours preserved at zero for scheduled scenarios). All fields optional — leave empty to run the scenario's published defaults.

Output parameters:

- `hourly` (array)
- `inputs` (object): Echo of the run's parameters.
- `summary` (object)

### `simulate_schedule` (~388 tokens)

Run a queueing simulation against an arbitrary 24-hour staffing schedule. Take this when the user describes a custom day shape that doesn't match a preset (e.g., 'my coffee shop is open 6am–10pm with 4 baristas off-peak, 7 at the 8am rush, 5 at the 4pm rush'). Inputs: `arrivalRates` (24-element array of customers/hr per hour-of-day) and `staffing` (24-element array of servers/hr); optional uniform `serviceTimeMinutes`. Use 0 in both arrays for closed hours (terminating system). Returns the same per-hour metrics + summary shape as simulate_mmc / simulate_scenario. Stronger fit than simulate_scenario when the user's shape doesn't match the four presets; stronger fit than simulate_mmc when they need per-hour variation. ANTI-FABRICATION: numbers come from a real DES run. Quote them VERBATIM. Do not round, estimate, or derive from training-data recall.

Input parameters:

- `arrivalDistribution` (string)
- `arrivalRates` (array, required): 24 hourly arrival rates (customers/hr, one per hour-of-day 0-23). Use 0 for closed hours (terminating system). Range 0-200 per hour.
- `serviceCoV` (number): CoV for service time when distribution is Normal or LogNormal. Range 0-5.
- `serviceDistribution` (string)
- `serviceTimeMinutes` (number): Mean service time in minutes per customer. Applies uniformly across hours. Range 0.1-180.
- `simulationDays` (integer): Days to simulate. Range 1-30.
- `staffing` (array, required): 24 hourly staffing counts (servers/hr, one per hour-of-day 0-23). Use 0 for closed hours. Range 0-50 per hour.

Output parameters:

- `hourly` (array)
- `inputs` (object): Echo of the run's parameters.
- `summary` (object)

### `compare_separate_vs_pooled` (~327 tokens)

Run the classic operations-research teaching demo: pooled queueing (one shared queue, c servers) vs separate queues (c independent queues, one server each, λ/c traffic to each). Both runs have identical total capacity (c × μ) and identical total arrivals (λ), so the offered load ρ is the same; the only structural difference is whether arrivals share a queue or split into c isolated streams. The pooled configuration ALWAYS produces shorter waits — that's the whole teaching point. Use this when the user asks 'should we pool our resources?' / 'should we cross-train?' / 'why do banks have one line instead of c?' / 'what's the cost of siloing my call center into specialist queues?'. Returns both runs side by side with the pooled-vs-separate wait delta. ANTI-FABRICATION: numbers come from two real DES runs. Quote them VERBATIM.

Input parameters:

- `arrivalRate` (number, required): Mean total arrival rate (λ). Pooled run takes all of it; separate run divides evenly across the c queues.
- `servers` (integer, required): Number of servers (c). Pooled: one queue feeds all c. Separate: c independent queues, each with one server and λ/c traffic. Range 2-50 (with c=1 there's nothing to compare).
- `serviceRate` (number, required): Mean service rate per server (μ, customers/hour each server finishes). Identical across both runs.
- `simulationDays` (integer): Days to simulate (same for both runs). Range 1-30.

Output parameters:

- `hourly` (array)
- `inputs` (object): Echo of the run's parameters.
- `summary` (object)

### `explain_queueing_theory` (~75 tokens)

Return a ~500-word educational explainer of M/M/c queueing theory: Little's Law, utilization, why averages mislead, how simulation relates to Erlang-C. No inputs. Use this when the user asks a conceptual 'why' or 'how does this work' question rather than asking for a number.

### `explain_advanced_patterns` (~101 tokens)

Return a textbook-level description of six queueing complexity patterns beyond basic M/M/c: abandonment/reneging, priority tiers, overflow routing, skills-based routing, compound service, and server outages. Use this when the user describes real-world complexity (customers hanging up, VIP queues, specialist escalation, agent breaks, transfers) that plain M/M/c doesn't model. The tool frames each pattern conceptually and points users at ChiAha for custom modeling.

### `recommend_staffing` (~400 tokens)

INVERSE of simulate_mmc — given an arrival rate, service rate, and a target average wait time, returns the SMALLEST number of servers needed to meet the target. Use this when the user asks 'how many servers do I need?' / 'what staffing keeps wait under N minutes?'. The tool runs a binary search over candidate server counts (up to maxServers, default 50), invoking the simulator for each candidate. Saves Claude from iterating simulate_mmc 3-5 times by hand. If even maxServers servers can't meet the target, the recommendation is null and the response includes the achieved wait so Claude can explain that the target is infeasible at the given load. ANTI-FABRICATION: `recommendedServers` and `achievedAvgWaitMinutes` come from real DES runs. Quote them VERBATIM. Do not propose a different number you think 'feels right'; this tool already binary-searches for the minimum that meets the target. If the user asks 'what if c=N?' for a specific N, call simulate_mmc with that c.

Input parameters:

- `arrivalDistribution` (string)
- `arrivalRate` (number, required): Mean arrivals per hour (λ).
- `maxServers` (integer): Search ceiling (default 50, max 50). If even this many servers can't meet the target, the tool returns null with the achieved wait.
- `serviceCoV` (number)
- `serviceDistribution` (string)
- `serviceRate` (number, required): Mean customers one server can finish per hour (μ). Must be > 0.
- `simulationDays` (integer): Days to simulate per candidate (default 7). Range 1-30. Lower = faster search; higher = less seed-to-seed variance.
- `targetAvgWaitMinutes` (number, required): Maximum average wait time you're willing to accept, in minutes. The tool returns the smallest server count that meets this target.

Output parameters:

- `achievedAvgWaitMinutes` (number)
- `note` (string)
- `offeredLoadAtRecommendation` (number): Present only when a feasible recommendation was found.
- `recommendedServers` (integer|null): Smallest c meeting the target. null when even maxServers can't meet it.
- `targetAvgWaitMinutes` (number)
- `trials` (array)

### `interpret_result` (~221 tokens)

Given an M/M/c configuration (arrivalRate, serviceRate, servers) and optionally an observed average wait, returns a queueing-theory framed interpretation: where you sit on the utilization curve, what ρ means in plain language, what one more or fewer server would qualitatively do, and which complexity factors (priority, abandonment, skills routing) might be hiding in real data the M/M/c model can't see. Use this to TEACH while answering — when the user wants context around a number, not just the number itself. Pure text computation, no simulation, no RNG — deterministic output.

Input parameters:

- `arrivalRate` (number, required): Mean arrivals per hour (λ).
- `observedAvgWaitMinutes` (number): Optional. The avg wait the user observed (from simulate_mmc, an Erlang-C calculator, or real measurements). If omitted, the tool computes ρ from the inputs and gives a parameter-only interpretation.
- `servers` (integer, required): Server count (c).
- `serviceRate` (number, required): Mean customers one server finishes per hour (μ).

### `compare_analytical_vs_simulated` (~284 tokens)

Run the same M/M/c configuration through BOTH the closed-form Erlang-C formula AND the discrete-event simulator, returning a side-by-side comparison with deltas. Use this when the user is validating QueueSim's engine against textbook values, learning queueing theory by watching simulation converge on the formula, or auditing a result that 'feels off' — agreement within ~5%% is the canonical sanity check for an M/M/c run. Pure-Exponential M/M/c only; the closed-form Erlang-C is undefined for other service distributions. Large deltas usually mean the simulation run was too short for steady-state — raise simulationDays. ANTI-FABRICATION: both sides come from real computation — closed-form is deterministic, simulation is stochastic but engine-backed. Quote both verbatim. Do not synthesize an 'average of the two' or recompute the formula from training-data recall.

Input parameters:

- `arrivalRate` (number, required): Mean arrivals per hour (λ).
- `servers` (integer, required): Number of parallel servers (c). Integer 1-50.
- `serviceRate` (number, required): Mean customers one server can finish per hour (μ). Must be > 0.
- `simulationDays` (integer): Days to simulate on the DES side. Closed-form is instant. Range 1-30; longer runs converge closer to the formula.

Output parameters:

- `analytical` (object)
- `delta` (object)
- `inputs` (object)
- `note` (string)
- `simulated` (object)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-queuesim-public/mcp-v1#diagnostics

## Score history

- 2026-08-03: 71
- 2026-08-02: 71
- 2026-08-01: 70
- 2026-07-31: 70
- 2026-07-30: 66
- 2026-07-29: 67
- 2026-07-28: 67
- 2026-07-27: 66
- 2026-07-26: 65

## Links

- Remote endpoint: https://queuesim.com/mcp/v1
- Repository: https://github.com/chiaha-ai/queuesim-site
- Changelog RSS feed: https://verifymcp.io/servers/com-queuesim-public/mcp-v1/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-queuesim-public/mcp-v1/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-queuesim-public/mcp-v1