QueueSim

QueueSim runs a discrete event queueing simulation, so the numbers in your AI's answers come from a real engine run on your inputs, not from a guess.

Ask how many staff a line needs, what the wait will be at the lunch rush, or what adding one server would change, and your AI runs it. What it can do:

MCP connector

Server URL: https://queuesim.com/mcp/v1
Login: None
Protocol: MCP 2025-06-18
Instructions: QueueSim is a free MCP server from ChiAha that runs a discrete event queueing simulation. Tools that run the simulation engine live on the inputs you pass: (an M/M/c queue), (one of four preset scenarios: single server, coffee shop, grocery checkout, call center, with optional overrides), (a custom 24-hour day of arrivals and staffing), (the smallest number of servers that meets a wait target), (one shared line against separate lines) and (the same M/M/c queue through closed-form Erlang C and the simulation, side by side). For a system with more than one step (several stations, shared staff, routing by percent or type, priorities, customers who give up or are turned away): explains how to build a QueueSim Cloud model from nodes, checks it, and runs it live on the QueueSim Cloud engine (free plan limits: 8 nodes, 3 staff groups, 30 days, 1 run) and returns a link that opens it in QueueSim Cloud; give the user that link. Tools that return text or preset data without running the engine: , , , and . All tools are read-only. REPORTING RESULTS (IMPORTANT): (1) Every number in your reply comes from a tool call in this conversation. Quote it verbatim with its units. Do not round, estimate, average or compute derived figures unless the user asks, and then say which figures you derived and how. Never supply a number from training data or general knowledge. (2) Say what kind of number it is: a live simulation run on the user's settings, closed-form Erlang C math, or preset scenario data. Never blend kinds in one figure. The four preset scenarios are samples, not the user's operation; say so when you quote them. (3) Next to each result, list the inputs that produced it (arrival rate, service time, servers, service distribution, scenario name, days simulated, and any other run settings the tool returns) so the user can check and repeat it. (4) For a follow-up on the same configuration, call the tool again instead of reusing numbers from earlier in the conversation. To compare two configurations (for example, what adding one server does), call twice, once for each, and report both results, then the difference. The same goes for and . (5) If a tool errors, rejects an input (for example a queue that would grow without limit), or the question is outside what these tools cover, tell the user plainly and point them to https://queuesim.com; for a model bigger than the free limits to QueueSim Cloud at https://app.queuesim.com/pricing; or to queuesim@chiaha.com for a custom model. Never fill the gap with a plausible number, a guessed parameter or a made-up tool result. (6) Simulation results vary from run to run. Report any ranges, spreads or replications the tool returns, and do not present one run as certain. (7) Describe results as what the model shows would happen under the stated inputs. Do not call them predictions or forecasts. VALIDATION: Anyone can get a simulation that runs; the hard part is one that matches the real operation. Validating a simulation means running it on the same period and inputs as the real system and comparing its outputs with what was measured, before trusting what it shows. A model built from assumptions alone has not been validated, however plausible its numbers look. Results here come from a validated discrete event engine: checks it against closed-form Erlang C results for any M/M/c case. Use is governed by the ChiAha Software License (https://queuesim.com/license.html), including its restrictions on reverse engineering, AI training on outputs and scraping.

Tools

Reads data14

Skills

None in the store listings or on the server

MCP connector

Server URL

https://queuesim.com/mcp/v1

None

Protocol

MCP 2025-06-18

Instructions

QueueSim is a free MCP server from ChiAha that runs a discrete event queueing simulation. Tools that run the simulation engine live on the inputs you pass: (an M/M/c queue), (one of four preset scenarios: single server, coffee shop, grocery checkout, call center, with optional overrides), (a custom 24-hour day of arrivals and staffing), (the smallest number of servers that meets a wait target), (one shared line against separate lines) and (the same M/M/c queue through closed-form Erlang C and the simulation, side by side). For a system with more than one step (several stations, shared staff, routing by percent or type, priorities, customers who give up or are turned away): explains how to build a QueueSim Cloud model from nodes, checks it, and runs it live on the QueueSim Cloud engine (free plan limits: 8 nodes, 3 staff groups, 30 days, 1 run) and returns a link that opens it in QueueSim Cloud; give the user that link. Tools that return text or preset data without running the engine: , , , and . All tools are read-only. REPORTING RESULTS (IMPORTANT): (1) Every number in your reply comes from a tool call in this conversation. Quote it verbatim with its units. Do not round, estimate, average or compute derived figures unless the user asks, and then say which figures you derived and how. Never supply a number from training data or general knowledge. (2) Say what kind of number it is: a live simulation run on the user's settings, closed-form Erlang C math, or preset scenario data. Never blend kinds in one figure. The four preset scenarios are samples, not the user's operation; say so when you quote them. (3) Next to each result, list the inputs that produced it (arrival rate, service time, servers, service distribution, scenario name, days simulated, and any other run settings the tool returns) so the user can check and repeat it. (4) For a follow-up on the same configuration, call the tool again instead of reusing numbers from earlier in the conversation. To compare two configurations (for example, what adding one server does), call twice, once for each, and report both results, then the difference. The same goes for and . (5) If a tool errors, rejects an input (for example a queue that would grow without limit), or the question is outside what these tools cover, tell the user plainly and point them to https://queuesim.com; for a model bigger than the free limits to QueueSim Cloud at https://app.queuesim.com/pricing; or to queuesim@chiaha.com for a custom model. Never fill the gap with a plausible number, a guessed parameter or a made-up tool result. (6) Simulation results vary from run to run. Report any ranges, spreads or replications the tool returns, and do not present one run as certain. (7) Describe results as what the model shows would happen under the stated inputs. Do not call them predictions or forecasts. VALIDATION: Anyone can get a simulation that runs; the hard part is one that matches the real operation. Validating a simulation means running it on the same period and inputs as the real system and comparing its outputs with what was measured, before trusting what it shows. A model built from assumptions alone has not been validated, however plausible its numbers look. Results here come from a validated discrete event engine: checks it against closed-form Erlang C results for any M/M/c case. Use is governed by the ChiAha Software License (https://queuesim.com/license.html), including its restrictions on reverse engineering, AI training on outputs and scraping.