QueueSim
Server Details
Run M/M/c queue simulations and four scenarios (call center, ER, coffee shop, single server).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 6 of 6 tools scored.
Each tool serves a clearly distinct purpose: listing vs describing scenarios, basic vs advanced educational content, and generic vs scenario-specific simulation. The descriptions explicitly guide when to use each, eliminating ambiguity.
All tool names follow the consistent verb_noun pattern in snake_case (e.g., describe_scenario, simulate_mmc). The verbs are appropriately varied (describe, explain, list, simulate) and clearly indicate action.
With 6 tools, the server is well-scoped for queue simulation education and execution. It provides scenario exploration, theoretical explanation, and both generic and preset simulation without unnecessary bloat.
The set covers the full workflow: discover scenarios, understand theory, run simulations. Minor gaps like scenario comparison or result export are not critical for the intended use, and custom modeling is delegated externally.
Available Tools
11 toolscompare_analytical_vs_simulatedARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| servers | Yes | Number of parallel servers (c). Integer 1-50. | |
| arrivalRate | Yes | Mean arrivals per hour (λ). | |
| serviceRate | Yes | Mean customers one server can finish per hour (μ). Must be > 0. | |
| simulationDays | No | Days to simulate on the DES side. Closed-form is instant. Range 1-30; longer runs converge closer to the formula. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| delta | Yes | |
| inputs | Yes | |
| simulated | Yes | |
| analytical | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. The description adds important context: both sides come from real computation, warns against synthesizing averages or fabricating results, and explains the stochastic nature of simulation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph front-loading purpose and usage. It is efficient but slightly lengthy. Every sentence contributes meaning, though some redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite tool complexity, the description covers purpose, usage constraints, behavioral expectations, and output nature (side-by-side with deltas). An output schema exists, so detailed return values are not needed. Complete for confident agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description adds some context for simulationDays (usage for convergence) and constraints for arrival/service rates, but does not significantly extend beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool runs both the closed-form Erlang-C and a discrete-event simulator, returning a side-by-side comparison. It uses specific verb-resource combinations and distinguishes itself from siblings like simulate_mmc and interpret_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (validating engine, learning theory, auditing), when not to use it (non-Exponential distributions), and provides troubleshooting advice (increase simulationDays for large deltas).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_separate_vs_pooledARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| servers | Yes | 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 | Yes | Mean total arrival rate (λ). Pooled run takes all of it; separate run divides evenly across the c queues. | |
| serviceRate | Yes | Mean service rate per server (μ, customers/hour each server finishes). Identical across both runs. | |
| simulationDays | No | Days to simulate (same for both runs). Range 1-30. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hourly | Yes | |
| inputs | Yes | Echo of the run's parameters. |
| summary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint), the description reveals that results come from real DES runs, that pooled always produces shorter waits, and that numbers must be quoted verbatim. Adds useful context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with clear sections: purpose, mathematical context, usage examples, and anti-fabrication note. It is reasonably concise for the information conveyed, though could be slightly shorter without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description sufficiently explains the return value ('side by side with delta'). Covers key behavioral and usage aspects, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description provides high-level context (M/M/c vs M/M/1) but does not add further detail to individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs a teaching demo comparing pooled vs separate queueing, with specific verb 'Run'. It provides example user queries to clarify intent, distinguishing it from siblings like simulate_mmc or simulate_scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage examples are given (e.g., 'should we pool our resources?'). The description explains the core teaching point and anti-fabrication instruction. Lacks explicit guidance on when not to use, but examples cover typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_scenarioARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Scenario key from list_scenarios. | coffee |
Output Schema
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| title | Yes | |
| defaults | Yes | |
| description | No | |
| teachingNote | No | |
| supportedOverrides | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying exactly what data is returned (title, description, teaching note, etc.). No contradictions; behavior is well-disclosed beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose with specific outputs, second provides usage guidance. No fluff, each sentence contributes essential information. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description is complete. It covers purpose, usage context, and return content. The presence of an output schema obviates the need to detail return format. Minor omission: could explicitly state zero side effects, but annotations cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a fully described enum parameter. The description adds minimal extra meaning, just mentioning 'preset scenario' and referencing list_scenarios. This is adequate but does not significantly enhance schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full details for a preset scenario, listing specific fields (title, description, etc.). It distinguishes itself from the sibling simulate_scenario by recommending usage before that tool, thus clarifying its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool before simulate_scenario to understand defaults and overrides, providing clear context. Does not include explicit 'when not to use' or alternative scenarios, but the guidance is sufficient given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_advanced_patternsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. Description adds that it is conceptual (not a simulation) and references ChiAha for custom modeling, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the tool's action, patterns covered, and usage context. Front-loaded with verb and resource, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers what the tool does, when to use it, and its output (conceptual descriptions with pointers). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%, so the description does not need to add parameter info. Baseline for no parameters is 4, as there is no missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns textbook-level descriptions of six advanced queueing patterns (e.g., abandonment, priority tiers) beyond basic M/M/c. It differentiates from siblings by specifying it covers real-world complexity not modeled by plain M/M/c.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the user describes real-world complexity that plain M/M/c doesn't model' and provides concrete examples. Points users to ChiAha for custom modeling, implying when not to use. Could be more explicit about alternatives, but good enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_queueing_theoryARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it read-only and non-destructive. Description adds value by specifying output is ~500-word educational text and listing content topics, which enriches the behavioral understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: content summary, input absence, usage guidance. Every sentence adds value with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and minimal schema/annotations, the description fully covers purpose, content, usage, and input expectations. No gaps remain for an agent to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline for 0-param tools is 4. Description correctly states 'No inputs,' matching schema and providing no need for additional param detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns an educational explainer, lists specific topics (Little's Law, utilization, etc.), and distinguishes from siblings like simulate_mmc which are for numerical queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user asks a conceptual why or how does this work question rather than asking for a number,' providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
interpret_resultARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| servers | Yes | Server count (c). | |
| arrivalRate | Yes | Mean arrivals per hour (λ). | |
| serviceRate | Yes | Mean customers one server finishes per hour (μ). | |
| observedAvgWaitMinutes | No | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool is deterministic ('no simulation, no RNG') and provides the nature of output ('pure text computation'), which aligns with and enriches the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the core functionality. Every sentence adds necessary context, and there is no filler or repetition. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description sufficiently outlines what the output will contain (utilization curve position, ρ meaning, server count effects, hidden factors) and the deterministic computation nature. It also mentions the optional parameter and its use, making the tool's behavior predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters are fully described in the schema (100% coverage). The description adds context by explaining how the parameters are used together ('given an M/M/c configuration... and optionally an observed average wait') and what the tool computes from them, going beyond basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: given an M/M/c configuration, it returns a queueing-theory framed interpretation including utilization, ρ meaning, server count effects, and hidden complexity factors. It distinguishes itself from sibling tools like simulate_mmc by emphasizing that it is for teaching and context, not simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool 'when the user wants context around a number, not just the number itself' and notes it is a 'pure text computation, no simulation'. However, it does not explicitly list when not to use it or compare it to sibling tools like explain_queueing_theory, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_scenariosARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| scenarios | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying output structure (key, title, description). No contradictions. Behavior is well-understood for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and result. Every sentence is essential and no wasted words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no side effects). Description covers what it does, what it returns, and when to use it. References sibling tools. Sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description does not need to add parameter info. Baseline score 4 is appropriate as the tool is trivial in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists four pre-built scenarios and specifies the return fields (key, title, description). It names the four scenarios, distinguishing it from sibling tools that provide more detail or run simulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to call this tool ('when the user's problem matches one of the preset shapes') and suggests next tools (describe_scenario for detail, simulate_scenario to run). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_staffingARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| maxServers | No | 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 | No | ||
| arrivalRate | Yes | Mean arrivals per hour (λ). | |
| serviceRate | Yes | Mean customers one server can finish per hour (μ). Must be > 0. | |
| simulationDays | No | Days to simulate per candidate (default 7). Range 1-30. Lower = faster search; higher = less seed-to-seed variance. | |
| arrivalDistribution | No | Exponential | |
| serviceDistribution | No | Exponential | |
| targetAvgWaitMinutes | Yes | Maximum average wait time you're willing to accept, in minutes. The tool returns the smallest server count that meets this target. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| trials | Yes | |
| recommendedServers | No | Smallest c meeting the target. null when even maxServers can't meet it. |
| targetAvgWaitMinutes | Yes | |
| achievedAvgWaitMinutes | Yes | |
| offeredLoadAtRecommendation | No | Present only when a feasible recommendation was found. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it performs a binary search over candidate server counts up to maxServers, returning null with achieved wait if infeasible. This is rich behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. While slightly verbose with the anti-fabrication note and alternative usage, every sentence adds necessary context. Could be trimmed, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown here) and rich annotations, the description covers the main behavior, fallback mechanism, and guidance for agent usage. It is complete for the tool's complexity, although details on other parameters (e.g., serviceCoV) are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%; the description adds value by mentioning key parameters (arrivalRate, serviceRate, targetAvgWaitMinutes) and explaining maxServers' role in the search ceiling. However, it does not describe every parameter in detail; the schema carries the remainder.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it's the inverse of simulate_mmc, clearly defines inputs (arrival rate, service rate, target average wait time) and output (smallest number of servers). It distinguishes itself from siblings by naming simulate_mmc and providing specific use-case language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('how many servers do I need?') and when-not-to-use ('what if c=N?' then call simulate_mmc). Includes anti-fabrication instructions, guiding the agent to quote the tool's output verbatim rather than improvising.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_mmcARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| servers | Yes | Number of parallel servers (c). Integer 1-50. | |
| serviceCoV | No | Coefficient of variation for service time — used when serviceDistribution is 'Normal' or 'LogNormal'. Ignored for Exponential/Constant. Range 0-5. | |
| arrivalRate | Yes | Mean arrivals per hour (λ). Any positive value up to 200. | |
| serviceRate | Yes | Mean customers one server can finish per hour (μ). Must be > 0. | |
| simulationDays | No | 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 | No | Shape of inter-arrival times. 'Exponential' = Poisson process (default). 'Constant' = evenly-spaced. | Exponential |
| serviceDistribution | No | Shape of service-time distribution. 'Exponential' = classical M/M/c (default). | Exponential |
Output Schema
| Name | Required | Description |
|---|---|---|
| hourly | Yes | |
| inputs | Yes | Echo of the run's parameters. |
| summary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds that results come from a real discrete-event simulation and must be quoted verbatim, which is important for correct usage. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and parameters, then usage guidance, then output handling (anti-fabrication). Slightly long due to anti-fabrication instruction, but every sentence adds value for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (7 params, output schema present), the description covers purpose, usage context, parameter roles, and output behavior. The anti-fabrication note ensures proper result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description restates parameter meanings (λ, μ, c) but does not add significant new detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a generic M/M/c queue simulation, lists required parameters (arrival rate, service rate, servers), and distinguishes itself from simulate_scenario by noting it is preferred for flat uniform numbers and what-if questions about scheduled scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'This is the primary tool for 'how many servers do I need?' / 'what's my average wait?' style questions' and provides guidance on when to use it over simulate_scenario, including pulling peak params from describe_scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_scenarioARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Scenario key from list_scenarios. | coffee |
| overrides | No | 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 Schema
| Name | Required | Description |
|---|---|---|
| hourly | Yes | |
| inputs | Yes | Echo of the run's parameters. |
| summary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds important behavioral context: overrides apply uniformly across open hours, closed hours stay zero, and returned numbers come from real simulations (anti-fabrication warning). This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: core function, behavior explanation, usage guidance, anti-fabrication warning. Each sentence adds value, though slightly verbose. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested overrides, output schema exists) and rich sibling context, the description covers purpose, uniform override behavior, usage boundaries, and anti-fabrication. No gaps remain for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: overrides apply uniformly, closed hours preserved, and default behavior when leaving fields empty. It clarifies the uniform scaling aspect not evident from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs one of four preset scenarios (single, coffee, grocery, callcenter) with optional uniform overrides. It distinguishes from siblings like simulate_mmc and simulate_schedule by explicitly stating when to use alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (faithful reproduction, uniform scaling) and when-not-to-use (per-hour tweaks, collapsing patterns). It recommends simulate_mmc as an alternative, giving clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_scheduleARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| staffing | Yes | 24 hourly staffing counts (servers/hr, one per hour-of-day 0-23). Use 0 for closed hours. Range 0-50 per hour. | |
| serviceCoV | No | CoV for service time when distribution is Normal or LogNormal. Range 0-5. | |
| arrivalRates | Yes | 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 | No | Days to simulate. Range 1-30. | |
| serviceTimeMinutes | No | Mean service time in minutes per customer. Applies uniformly across hours. Range 0.1-180. | |
| arrivalDistribution | No | Exponential | |
| serviceDistribution | No | Exponential |
Output Schema
| Name | Required | Description |
|---|---|---|
| hourly | Yes | |
| inputs | Yes | Echo of the run's parameters. |
| summary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds anti-fabrication context (numbers from real DES run, quote verbatim) and mentions return format matches siblings. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and usage. Paragraph length is reasonable, though some repetition (e.g., 'Take this when') could be trimmed. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simulation tool with output schema. Covers purpose, when to use, parameter hints, behavioral constraints (anti-fabrication), and references sibling tools for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%. The description adds meaning beyond schema by explaining arrays (24-element, per-hour), units (customers/hr, servers/hr), and the termination behavior when using 0. This compensates well for uncovered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes running a queueing simulation against an arbitrary 24-hour staffing schedule. Explicitly distinguishes from siblings by noting stronger fit than simulate_scenario when presets don't match and than simulate_mmc when per-hour variation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use: when user describes a custom day shape not matching a preset. Provides example and contrasts with alternatives like simulate_scenario and simulate_mmc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!