QueueSim
Run M/M/c queue simulations and four scenarios (call center, ER, coffee shop, single server).
| Endpoint | https://queuesim.com/mcp/v1 (streamable-http) |
|---|---|
| Registry version | 1.0.0 |
| Now | 11 tools · grade D (60) · pin ts_468418d7f019b8ff4bcebd85bb6cbba0 · protocol 2025-06-18 |
| First / last listed | 2026-11-08 01:29 UTC / 2026-11-08 01:29 UTC |
| Grade over time | 2026-11-08: D (60), 11 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: simulate_mmc list_scenarios describe_scenario simulate_scenario simulate_schedule compare_separate_vs_pooled explain_queueing_theory explain_advanced_patterns recommend_staffing interpret_result compare_analytical_vs_simulated
simulate_mmc | 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 params: arrivalRate*, serviceRate*, servers*, arrivalDistribution, serviceDistribution, serviceCoV, simulationDays |
list_scenarios | 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. params: none |
describe_scenario | 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. params: name* |
simulate_scenario | 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 params: name*, overrides |
simulate_schedule | 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 params: arrivalRates*, staffing*, serviceTimeMinutes, simulationDays, arrivalDistribution, serviceDistribution, serviceCoV |
compare_separate_vs_pooled | 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 po params: arrivalRate*, serviceRate*, servers*, simulationDays |
explain_queueing_theory | 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. params: none |
explain_advanced_patterns | 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 p params: none |
recommend_staffing | 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. params: arrivalRate*, serviceRate*, targetAvgWaitMinutes*, maxServers, simulationDays, arrivalDistribution, serviceDistribution, serviceCoV |
interpret_result | 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 params: arrivalRate*, serviceRate*, servers*, observedAvgWaitMinutes |
compare_analytical_vs_simulated | 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 params: arrivalRate*, serviceRate*, servers*, simulationDays |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.