Koskamo

QueueSim MCP

An official MCP server provided by ChiAha that allows AI assistants to run discrete-event queue simulations and staffing what-if analyses. It supports building M/M/c queues, running preset scenarios, and comparing analytical results against simulation outputs without requiring authentication.

Endpoint and access

No sign-in to connect and list tools. Individual tools may still need a vendor account, credentials, or permissions; check the documented prerequisites.

QueueSim MCP logo, by ChiAhaVendor evidenceStreamable HTTPNo sign-inEndpoint checked 2026-11-06Operated by ChiAha
MCP endpoint (Streamable HTTP)
https://queuesim.com/mcp/v1
Vendor documentation

What its tools do

11 tools, grouped by the hints the server advertises. Hints are self-declared, not verified behavior.

11 of 11 have a description · 11 of 11 declare behavior hints · 6 of 8 with parameters document them all

Checks and signals

Each line is separate evidence, not a trust score.

  • Passed Endpoint answered the live check ·
  • Passed Official MCP Registry namespace is tied to queuesim.com ·
  • Passed Endpoint is on the registry namespace domain ·
  • Availability 1 of 1 checks passed in 30 days

What you can do with it

  • Run M/M/c queue simulations and four scenarios (call center, ER, coffee shop, single server)
  • Build a queue from arrivals, service rate and staff using simulate_mmc
  • Check the engine by comparing analytical vs simulated results for M/M/c queues

Source and maintenance

Vendor evidenceRegistry 1.0.0
Maintenance checked

Protocol and capabilities

Server
queuesim-v1 1.0.1
MCP protocol negotiated in check
2025-06-18
Tools
11 advertised
Resources
Not advertised
Resource templates
Not advertised
Prompts
Not advertised
Server-advertised capabilities
{
  "tools": {}
}

Server-provided instructions

Untrusted server output shown for inspection. It is not Koskamo guidance and is excluded from knowledge search.

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: simulate_mmc (an M/M/c queue), simulate_scenario (one of four preset scenarios: single server, coffee shop, grocery checkout, call center, with optional overrides), simulate_schedule (a custom 24-hour day of arrivals and staffing), recommend_staffing (the smallest number of servers that meets a wait target), compare_separate_vs_pooled (one shared line against separate lines) and compare_analytical_vs_simulated (the same M/M/c queue through closed-form Erlang C and the simulation, side by side). Tools that return text or preset data without running the engine: list_scenarios, describe_scenario, interpret_result, explain_queueing_theory and explain_advanced_patterns. 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 simulate_mmc twice, once for each, and report both results, then the difference. The same goes for simulate_scenario and simulate_schedule. (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 system beyond one line (several steps, shared staff, routing by percent or type, priorities, customers who give up) to QueueSim Cloud at https://app.queuesim.com/ (free plan, no sign-up); 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: compare_analytical_vs_simulated 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

11 advertised

simulate_mmc
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

simulate_mmc input schema
{
  "type": "object",
  "required": [
    "arrivalRate",
    "serviceRate",
    "servers"
  ],
  "properties": {
    "servers": {
      "type": "integer",
      "default": 2,
      "maximum": 50,
      "minimum": 1,
      "description": "Number of parallel servers (c). Integer 1-50."
    },
    "serviceCoV": {
      "type": "number",
      "maximum": 5,
      "minimum": 0,
      "description": "Coefficient of variation for service time — used when serviceDistribution is 'Normal' or 'LogNormal'. Ignored for Exponential/Constant. Range 0-5."
    },
    "arrivalRate": {
      "type": "number",
      "default": 20,
      "maximum": 200,
      "description": "Mean arrivals per hour (λ). Any positive value up to 200.",
      "exclusiveMinimum": 0
    },
    "serviceRate": {
      "type": "number",
      "default": 12,
      "description": "Mean customers one server can finish per hour (μ). Must be > 0.",
      "exclusiveMinimum": 0
    },
    "simulationDays": {
      "type": "integer",
      "default": 7,
      "maximum": 30,
      "minimum": 1,
      "description": "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."
    },
    "arrivalDistribution": {
      "enum": [
        "Exponential",
        "Constant"
      ],
      "type": "string",
      "default": "Exponential",
      "description": "Shape of inter-arrival times. 'Exponential' = Poisson process (default). 'Constant' = evenly-spaced."
    },
    "serviceDistribution": {
      "enum": [
        "Exponential",
        "Constant",
        "Normal",
        "LogNormal"
      ],
      "type": "string",
      "default": "Exponential",
      "description": "Shape of service-time distribution. 'Exponential' = classical M/M/c (default)."
    }
  }
}
simulate_mmc output schema
{
  "type": "object",
  "required": [
    "inputs",
    "summary",
    "hourly"
  ],
  "properties": {
    "hourly": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "hour": {
            "type": "integer"
          },
          "label": {
            "type": "string"
          },
          "avgArrivals": {
            "type": "number"
          },
          "maxArrivals": {
            "type": "integer"
          },
          "avgDepartures": {
            "type": "number"
          },
          "maxDepartures": {
            "type": "integer"
          },
          "serversOnDuty": {
            "type": "integer"
          },
          "avgQueueLength": {
            "type": "number"
          },
          "avgWaitMinutes": {
            "type": "number"
          },
          "maxQueueLength": {
            "type": "number"
          },
          "maxWaitMinutes": {
            "type": "number"
          }
        }
      }
    },
    "inputs": {
      "type": "object",
      "description": "Echo of the run's parameters."
    },
    "summary": {
      "type": "object",
      "required": [
        "totalArrivals",
        "totalServed",
        "effectiveDays",
        "overallAvgWaitMinutes"
      ],
      "properties": {
        "offeredLoad": {
          "type": [
            "number",
            "null"
          ]
        },
        "totalServed": {
          "type": "integer"
        },
        "effectiveDays": {
          "type": "integer"
        },
        "totalArrivals": {
          "type": "integer"
        },
        "overallAvgWaitMinutes": {
          "type": "number"
        }
      }
    }
  }
}
simulate_mmc annotations
{
  "title": "Run M/M/c queue simulation",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": false,
  "destructiveHint": false
}
list_scenarios
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

list_scenarios input schema
{
  "type": "object",
  "properties": {}
}
list_scenarios output schema
{
  "type": "object",
  "required": [
    "scenarios"
  ],
  "properties": {
    "scenarios": {
      "type": "array",
      "items": {
        "type": "object",
        "required": [
          "key",
          "title",
          "description"
        ],
        "properties": {
          "key": {
            "type": "string"
          },
          "title": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        }
      }
    }
  }
}
list_scenarios annotations
{
  "title": "List preset scenarios",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
describe_scenario
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

describe_scenario input schema
{
  "type": "object",
  "required": [
    "name"
  ],
  "properties": {
    "name": {
      "enum": [
        "single",
        "coffee",
        "grocery",
        "callcenter"
      ],
      "type": "string",
      "default": "coffee",
      "description": "Scenario key from list_scenarios."
    }
  }
}
describe_scenario output schema
{
  "type": "object",
  "required": [
    "key",
    "title",
    "defaults"
  ],
  "properties": {
    "key": {
      "type": "string"
    },
    "title": {
      "type": "string"
    },
    "defaults": {
      "type": "object"
    },
    "description": {
      "type": "string"
    },
    "teachingNote": {
      "type": "string"
    },
    "supportedOverrides": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  }
}
describe_scenario annotations
{
  "title": "Describe preset scenario",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
simulate_scenario
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

simulate_scenario input schema
{
  "type": "object",
  "required": [
    "name"
  ],
  "properties": {
    "name": {
      "enum": [
        "single",
        "coffee",
        "grocery",
        "callcenter"
      ],
      "type": "string",
      "default": "coffee",
      "description": "Scenario key from list_scenarios."
    },
    "overrides": {
      "type": "object",
      "properties": {
        "servers": {
          "type": "integer",
          "maximum": 50,
          "minimum": 1,
          "description": "Override server count applied to every hour the scenario had staff."
        },
        "serviceCoV": {
          "type": "number",
          "maximum": 5,
          "minimum": 0
        },
        "arrivalRate": {
          "type": "number",
          "maximum": 200,
          "description": "Override arrival rate (customers/hr) applied to every hour the scenario was open.",
          "exclusiveMinimum": 0
        },
        "simulationDays": {
          "type": "integer",
          "default": 7,
          "maximum": 30,
          "minimum": 1,
          "description": "Days to simulate (default 7). Range 1-30 — longer runs are not supported on the public surface."
        },
        "serviceTimeMinutes": {
          "type": "number",
          "description": "Override mean service time (minutes per customer).",
          "exclusiveMinimum": 0
        },
        "arrivalDistribution": {
          "enum": [
            "Exponential",
            "Constant"
          ],
          "type": "string"
        },
        "serviceDistribution": {
          "enum": [
            "Exponential",
            "Constant",
            "Normal",
            "LogNormal"
          ],
          "type": "string"
        }
      },
      "description": "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."
    }
  }
}
simulate_scenario output schema
{
  "type": "object",
  "required": [
    "inputs",
    "summary",
    "hourly"
  ],
  "properties": {
    "hourly": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "hour": {
            "type": "integer"
          },
          "label": {
            "type": "string"
          },
          "avgArrivals": {
            "type": "number"
          },
          "maxArrivals": {
            "type": "integer"
          },
          "avgDepartures": {
            "type": "number"
          },
          "maxDepartures": {
            "type": "integer"
          },
          "serversOnDuty": {
            "type": "integer"
          },
          "avgQueueLength": {
            "type": "number"
          },
          "avgWaitMinutes": {
            "type": "number"
          },
          "maxQueueLength": {
            "type": "number"
          },
          "maxWaitMinutes": {
            "type": "number"
          }
        }
      }
    },
    "inputs": {
      "type": "object",
      "description": "Echo of the run's parameters."
    },
    "summary": {
      "type": "object",
      "required": [
        "totalArrivals",
        "totalServed",
        "effectiveDays",
        "overallAvgWaitMinutes"
      ],
      "properties": {
        "offeredLoad": {
          "type": [
            "number",
            "null"
          ]
        },
        "totalServed": {
          "type": "integer"
        },
        "effectiveDays": {
          "type": "integer"
        },
        "totalArrivals": {
          "type": "integer"
        },
        "overallAvgWaitMinutes": {
          "type": "number"
        }
      }
    }
  }
}
simulate_scenario annotations
{
  "title": "Run preset scenario",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": false,
  "destructiveHint": false
}
simulate_schedule
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

simulate_schedule input schema
{
  "type": "object",
  "required": [
    "arrivalRates",
    "staffing"
  ],
  "properties": {
    "staffing": {
      "type": "array",
      "items": {
        "type": "integer",
        "maximum": 50,
        "minimum": 0
      },
      "maxItems": 24,
      "minItems": 24,
      "description": "24 hourly staffing counts (servers/hr, one per hour-of-day 0-23). Use 0 for closed hours. Range 0-50 per hour."
    },
    "serviceCoV": {
      "type": "number",
      "maximum": 5,
      "minimum": 0,
      "description": "CoV for service time when distribution is Normal or LogNormal. Range 0-5."
    },
    "arrivalRates": {
      "type": "array",
      "items": {
        "type": "number",
        "maximum": 200,
        "minimum": 0
      },
      "maxItems": 24,
      "minItems": 24,
      "description": "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."
    },
    "simulationDays": {
      "type": "integer",
      "default": 7,
      "maximum": 30,
      "minimum": 1,
      "description": "Days to simulate. Range 1-30."
    },
    "serviceTimeMinutes": {
      "type": "number",
      "default": 5,
      "maximum": 180,
      "description": "Mean service time in minutes per customer. Applies uniformly across hours. Range 0.1-180.",
      "exclusiveMinimum": 0
    },
    "arrivalDistribution": {
      "enum": [
        "Exponential",
        "Constant"
      ],
      "type": "string",
      "default": "Exponential"
    },
    "serviceDistribution": {
      "enum": [
        "Exponential",
        "Constant",
        "Normal",
        "LogNormal"
      ],
      "type": "string",
      "default": "Exponential"
    }
  }
}
simulate_schedule output schema
{
  "type": "object",
  "required": [
    "inputs",
    "summary",
    "hourly"
  ],
  "properties": {
    "hourly": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "hour": {
            "type": "integer"
          },
          "label": {
            "type": "string"
          },
          "avgArrivals": {
            "type": "number"
          },
          "maxArrivals": {
            "type": "integer"
          },
          "avgDepartures": {
            "type": "number"
          },
          "maxDepartures": {
            "type": "integer"
          },
          "serversOnDuty": {
            "type": "integer"
          },
          "avgQueueLength": {
            "type": "number"
          },
          "avgWaitMinutes": {
            "type": "number"
          },
          "maxQueueLength": {
            "type": "number"
          },
          "maxWaitMinutes": {
            "type": "number"
          }
        }
      }
    },
    "inputs": {
      "type": "object",
      "description": "Echo of the run's parameters."
    },
    "summary": {
      "type": "object",
      "required": [
        "totalArrivals",
        "totalServed",
        "effectiveDays",
        "overallAvgWaitMinutes"
      ],
      "properties": {
        "offeredLoad": {
          "type": [
            "number",
            "null"
          ]
        },
        "totalServed": {
          "type": "integer"
        },
        "effectiveDays": {
          "type": "integer"
        },
        "totalArrivals": {
          "type": "integer"
        },
        "overallAvgWaitMinutes": {
          "type": "number"
        }
      }
    }
  }
}
simulate_schedule annotations
{
  "title": "Run a custom 24-hour schedule simulation",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": false,
  "destructiveHint": false
}
compare_separate_vs_pooled
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

compare_separate_vs_pooled input schema
{
  "type": "object",
  "required": [
    "arrivalRate",
    "serviceRate",
    "servers"
  ],
  "properties": {
    "servers": {
      "type": "integer",
      "default": 3,
      "maximum": 50,
      "minimum": 2,
      "description": "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)."
    },
    "arrivalRate": {
      "type": "number",
      "default": 30,
      "maximum": 200,
      "description": "Mean total arrival rate (λ). Pooled run takes all of it; separate run divides evenly across the c queues.",
      "exclusiveMinimum": 0
    },
    "serviceRate": {
      "type": "number",
      "default": 12,
      "description": "Mean service rate per server (μ, customers/hour each server finishes). Identical across both runs.",
      "exclusiveMinimum": 0
    },
    "simulationDays": {
      "type": "integer",
      "default": 7,
      "maximum": 30,
      "minimum": 1,
      "description": "Days to simulate (same for both runs). Range 1-30."
    }
  }
}
compare_separate_vs_pooled output schema
{
  "type": "object",
  "required": [
    "inputs",
    "summary",
    "hourly"
  ],
  "properties": {
    "hourly": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "hour": {
            "type": "integer"
          },
          "label": {
            "type": "string"
          },
          "avgArrivals": {
            "type": "number"
          },
          "maxArrivals": {
            "type": "integer"
          },
          "avgDepartures": {
            "type": "number"
          },
          "maxDepartures": {
            "type": "integer"
          },
          "serversOnDuty": {
            "type": "integer"
          },
          "avgQueueLength": {
            "type": "number"
          },
          "avgWaitMinutes": {
            "type": "number"
          },
          "maxQueueLength": {
            "type": "number"
          },
          "maxWaitMinutes": {
            "type": "number"
          }
        }
      }
    },
    "inputs": {
      "type": "object",
      "description": "Echo of the run's parameters."
    },
    "summary": {
      "type": "object",
      "required": [
        "totalArrivals",
        "totalServed",
        "effectiveDays",
        "overallAvgWaitMinutes"
      ],
      "properties": {
        "offeredLoad": {
          "type": [
            "number",
            "null"
          ]
        },
        "totalServed": {
          "type": "integer"
        },
        "effectiveDays": {
          "type": "integer"
        },
        "totalArrivals": {
          "type": "integer"
        },
        "overallAvgWaitMinutes": {
          "type": "number"
        }
      }
    }
  }
}
compare_separate_vs_pooled annotations
{
  "title": "Compare pooled (M/M/c) vs separate (c × M/M/1) queueing",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": false,
  "destructiveHint": false
}
explain_queueing_theory
Advertised by the server during the last successful anonymous check.
Advertised read-only

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_queueing_theory input schema
{
  "type": "object",
  "properties": {}
}
explain_queueing_theory annotations
{
  "title": "Queueing theory primer",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
explain_advanced_patterns
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

explain_advanced_patterns input schema
{
  "type": "object",
  "properties": {}
}
explain_advanced_patterns annotations
{
  "title": "Advanced patterns primer",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
recommend_staffing
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

recommend_staffing input schema
{
  "type": "object",
  "required": [
    "arrivalRate",
    "serviceRate",
    "targetAvgWaitMinutes"
  ],
  "properties": {
    "maxServers": {
      "type": "integer",
      "default": 50,
      "maximum": 50,
      "minimum": 1,
      "description": "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": {
      "type": "number",
      "maximum": 5,
      "minimum": 0
    },
    "arrivalRate": {
      "type": "number",
      "default": 20,
      "maximum": 200,
      "description": "Mean arrivals per hour (λ).",
      "exclusiveMinimum": 0
    },
    "serviceRate": {
      "type": "number",
      "default": 12,
      "description": "Mean customers one server can finish per hour (μ). Must be > 0.",
      "exclusiveMinimum": 0
    },
    "simulationDays": {
      "type": "integer",
      "default": 7,
      "maximum": 30,
      "minimum": 1,
      "description": "Days to simulate per candidate (default 7). Range 1-30. Lower = faster search; higher = less seed-to-seed variance."
    },
    "arrivalDistribution": {
      "enum": [
        "Exponential",
        "Constant"
      ],
      "type": "string",
      "default": "Exponential"
    },
    "serviceDistribution": {
      "enum": [
        "Exponential",
        "Constant",
        "Normal",
        "LogNormal"
      ],
      "type": "string",
      "default": "Exponential"
    },
    "targetAvgWaitMinutes": {
      "type": "number",
      "default": 3,
      "minimum": 0,
      "description": "Maximum average wait time you're willing to accept, in minutes. The tool returns the smallest server count that meets this target."
    }
  }
}
recommend_staffing output schema
{
  "type": "object",
  "required": [
    "achievedAvgWaitMinutes",
    "targetAvgWaitMinutes",
    "trials",
    "note"
  ],
  "properties": {
    "note": {
      "type": "string"
    },
    "trials": {
      "type": "array",
      "items": {
        "type": "object",
        "required": [
          "servers",
          "avgWaitMinutes"
        ],
        "properties": {
          "servers": {
            "type": "integer"
          },
          "avgWaitMinutes": {
            "type": "number"
          }
        }
      }
    },
    "recommendedServers": {
      "type": [
        "integer",
        "null"
      ],
      "description": "Smallest c meeting the target. null when even maxServers can't meet it."
    },
    "targetAvgWaitMinutes": {
      "type": "number"
    },
    "achievedAvgWaitMinutes": {
      "type": "number"
    },
    "offeredLoadAtRecommendation": {
      "type": "number",
      "description": "Present only when a feasible recommendation was found."
    }
  }
}
recommend_staffing annotations
{
  "title": "Recommend minimum staffing for a wait-time target",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": false,
  "destructiveHint": false
}
interpret_result
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

interpret_result input schema
{
  "type": "object",
  "required": [
    "arrivalRate",
    "serviceRate",
    "servers"
  ],
  "properties": {
    "servers": {
      "type": "integer",
      "default": 2,
      "maximum": 50,
      "minimum": 1,
      "description": "Server count (c)."
    },
    "arrivalRate": {
      "type": "number",
      "default": 20,
      "maximum": 200,
      "description": "Mean arrivals per hour (λ).",
      "exclusiveMinimum": 0
    },
    "serviceRate": {
      "type": "number",
      "default": 12,
      "description": "Mean customers one server finishes per hour (μ).",
      "exclusiveMinimum": 0
    },
    "observedAvgWaitMinutes": {
      "type": "number",
      "minimum": 0,
      "description": "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."
    }
  }
}
interpret_result annotations
{
  "title": "Interpret M/M/c result",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": true,
  "destructiveHint": false
}
compare_analytical_vs_simulated
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

compare_analytical_vs_simulated input schema
{
  "type": "object",
  "required": [
    "arrivalRate",
    "serviceRate",
    "servers"
  ],
  "properties": {
    "servers": {
      "type": "integer",
      "default": 2,
      "maximum": 50,
      "minimum": 1,
      "description": "Number of parallel servers (c). Integer 1-50."
    },
    "arrivalRate": {
      "type": "number",
      "default": 20,
      "maximum": 200,
      "description": "Mean arrivals per hour (λ).",
      "exclusiveMinimum": 0
    },
    "serviceRate": {
      "type": "number",
      "default": 12,
      "description": "Mean customers one server can finish per hour (μ). Must be > 0.",
      "exclusiveMinimum": 0
    },
    "simulationDays": {
      "type": "integer",
      "default": 7,
      "maximum": 30,
      "minimum": 1,
      "description": "Days to simulate on the DES side. Closed-form is instant. Range 1-30; longer runs converge closer to the formula."
    }
  }
}
compare_analytical_vs_simulated output schema
{
  "type": "object",
  "required": [
    "inputs",
    "analytical",
    "simulated",
    "delta"
  ],
  "properties": {
    "note": {
      "type": "string"
    },
    "delta": {
      "type": "object",
      "properties": {
        "note": {
          "type": "string"
        },
        "avgQueueLength": {
          "type": "number"
        },
        "avgWaitMinutes": {
          "type": "number"
        },
        "avgWaitPercent": {
          "type": "number"
        }
      }
    },
    "inputs": {
      "type": "object"
    },
    "simulated": {
      "type": "object",
      "required": [
        "avgWaitMinutes",
        "avgQueueLength",
        "offeredLoad",
        "totalServed"
      ],
      "properties": {
        "offeredLoad": {
          "type": "number"
        },
        "totalServed": {
          "type": "integer"
        },
        "effectiveDays": {
          "type": "integer"
        },
        "avgQueueLength": {
          "type": "number"
        },
        "avgWaitMinutes": {
          "type": "number"
        }
      }
    },
    "analytical": {
      "type": "object",
      "required": [
        "avgWaitMinutes",
        "avgQueueLength",
        "offeredLoad",
        "probabilityOfWaiting"
      ],
      "properties": {
        "offeredLoad": {
          "type": "number"
        },
        "avgQueueLength": {
          "type": "number"
        },
        "avgWaitMinutes": {
          "type": "number"
        },
        "probabilityOfWaiting": {
          "type": "number"
        }
      }
    }
  }
}
compare_analytical_vs_simulated annotations
{
  "title": "Compare closed-form Erlang-C vs DES simulation",
  "readOnlyHint": true,
  "openWorldHint": false,
  "idempotentHint": false,
  "destructiveHint": false
}

Prompts

Not advertised

No prompt definitions available.

Resources

Not advertised

No resource definitions available.

90-day uptime

A lightweight connection check about every six hours, sampled on hosts with many listings. It shows the server answered, not that its tools work.

Too few checks for a percentage yet (3 of 3 answered).

  1. 2026-11-07: 2 of 2 checks answered
  2. 2026-11-09: 1 of 1 checks answered

30-day availability

Aggregated from read-only remote checks; this is not a tool-execution or security guarantee.

Successful checks
1 of 1 (100%)
Average latency
322 ms
95th percentile latency
322 ms

Maintenance history

Public check and source-refresh events. Editorial and ownership records remain private.

  • · probe · passed · 322 ms · metadata changed · 11 tool(s)

Connect from your client

Each snippet registers the same endpoint; pick the client you use.

This server is operated by the named third party. Listing and endpoint checks are not an endorsement or a security audit. Review the operator's permissions, terms, and data handling before connecting. How listings are checked and corrected.

Claude Code

Run this once in a terminal. It registers the remote server. Use --scope project to write .mcp.json for the repo.
Claude Code configuration
claude mcp add --transport http queuesim-mcp https://queuesim.com/mcp/v1

Codex

Run this once. Codex stores MCP servers in ~/.codex/config.toml (or .codex/config.toml in a trusted project).
Codex configuration
codex mcp add queuesim-mcp --url https://queuesim.com/mcp/v1

Cursor

Merge this server into .cursor/mcp.json in your project, then enable queuesim-mcp in your MCP settings.
Cursor configuration
{
  "mcpServers": {
    "queuesim-mcp": {
      "url": "https://queuesim.com/mcp/v1"
    }
  }
}

Cline

Merge this into cline_mcp_settings.json (Cline → MCP Servers → Configure).
Cline configuration
{
  "mcpServers": {
    "queuesim-mcp": {
      "type": "streamableHttp",
      "url": "https://queuesim.com/mcp/v1",
      "disabled": false
    }
  }
}

VS Code

Merge this server into .vscode/mcp.json. Use MCP: List Servers to start queuesim-mcp and inspect its tools.
VS Code configuration
{
  "servers": {
    "queuesim-mcp": {
      "type": "http",
      "url": "https://queuesim.com/mcp/v1"
    }
  }
}

Gemini CLI

Run this once. It writes .gemini/settings.json in the current project; pass --scope user for ~/.gemini/settings.json.
Gemini CLI configuration
gemini mcp add --transport http queuesim-mcp https://queuesim.com/mcp/v1

Claude Desktop

Open Claude Settings > Connectors > Add custom connector, enter this server URL and enable it for the conversation. This is a manual remote-connector handoff, not a desktop JSON configuration.
Claude Desktop configuration
https://queuesim.com/mcp/v1

Windsurf

Merge this into ~/.codeium/windsurf/mcp_config.json, then refresh MCP in Cascade. Windsurf remote servers use serverUrl, not url.
Windsurf configuration
{
  "mcpServers": {
    "queuesim-mcp": {
      "serverUrl": "https://queuesim.com/mcp/v1"
    }
  }
}

Let your agent find its tools

Find servers like QueueSim MCP from your agent. Add Koskamo once to search the index for endpoints, access requirements, and client setup. Public discovery needs no key.

Do you run QueueSim MCP?

Prove ownership with a DNS record, a well-known file, or your Official MCP Registry entry, and your edits publish immediately. Proofs are re-checked weekly; admins can still hide or remove a listing.

Claim this listing