QueueSim

skills: {'id': 'simulate_mmc', 'name': 'simulate_mmc', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'list_scenarios', 'name': 'list_scenarios', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'describe_scenario', 'name': 'describe_scenario', 'description': '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.', 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'simulate_scenario', 'name': 'simulate_scenario', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'simulate_schedule', 'name': 'simulate_schedule', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'compare_separate_vs_pooled', 'name': 'compare_separate_vs_pooled', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'explain_queueing_theory', 'name': 'explain_queueing_theory', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'explain_advanced_patterns', 'name': 'explain_advanced_patterns', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}; uptime_30d 1.0%; p95 15.6ms; conformance: pass

How to connect

https://queuesim.com/mcp/v1

curl -X POST https://queuesim.com/mcp/v1 \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}'