QueueSim

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses key behavioral traits: 'closed-form is deterministic, simulation is stochastic but engine-backed,' the anti-fabrication rule to quote both verbatim, and the troubleshooting hint that large deltas mean simulation too short. It also warns against synthesizing averages or recomputing from training-data recall. This provides substantial 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 front-loaded with a clear purpose statement, followed by when-to-use, constraints, troubleshooting, and anti-fabrication rules. Every sentence carries important information without redundancy. The length is justified by the tool's complexity and the critical behavioral guidance needed for correct usage.

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 has an output schema and 4 well-documented parameters, the description covers purpose, usage scenarios, exclusions, troubleshooting, and behavioral expectations. It explicitly notes the pure-M/M/c limitation and how to react to large deltas. With annotations and output schema already providing structured metadata, this description is fully complete for an AI agent to select and invoke the tool 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?

The input schema already documents all 4 parameters with 100% coverage, so the baseline is 3. The description adds value by tying the 'simulationDays' parameter to a troubleshooting scenario ('raise simulationDays' for large deltas) and confirms the M/M/c scope for the service distribution. This incremental guidance justifies a score above baseline.

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 the same M/M/c configuration through both the Erlang-C formula and the discrete-event simulator, returning a side-by-side comparison with deltas. It uses a specific verb ('Run'), names the exact resources, and is easily distinguished from siblings like 'compare_separate_vs_pooled' or 'simulate_mmc'.

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 says when to use this tool: 'validating QueueSim's engine against textbook values, learning queueing theory... or auditing a result that feels off.' It also provides an exclusion criterion: 'Pure-Exponential M/M/c only; the closed-form Erlang-C is undefined for other service distributions.' This gives 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and destructiveHint annotations, the description adds key behavioral context: 'The pooled configuration ALWAYS produces shorter waits — that's the whole teaching point' and 'ANTI-FABRICATION: numbers come from two real DES runs. Quote them VERBATIM.' These are non-obvious behaviors not disclosed by 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 efficiently structured, with a clear statement of the demo, the teaching point, usage triggers, return value, and an anti-fabrication warning. Every sentence serves a purpose, and the text is front-loaded with the core action.

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 description fully covers the tool's context: it explains the comparison methodology, the invariant load, the expected outcome, typical user intents, and the nature of the results. An output schema exists, so the return description is sufficient.

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%, so parameters are well-documented. The description adds conceptual meaning by explaining that 'Both runs have identical total capacity (c × μ) and identical total arrivals (λ)' and that separate queues each get λ/c traffic, which enriches the understanding of arrivalRate and serviceRate relationships.

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: '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).' It distinguishes from siblings like compare_analytical_vs_simulated by focusing on pooled vs. separate queue structures.

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 triggers are provided: '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?'.' This clearly explains when to choose this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds contextual value by specifying the returned fields and that it reveals the 'default shape' for overrides, which is behavior beyond what annotations state. No contradiction exists, so a 4 is appropriate.

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 two sentences, front-loaded with the tool's action and content, followed by a clear usage directive. No redundant words, and each sentence serves a distinct purpose (what it does and when to use it).

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?

With one enum parameter, a rich output schema, and comprehensive annotations, the tool is simple. The description provides all necessary context: what it returns, the specific fields, and how it fits into the workflow (before simulate_scenario). There's no missing information for this level of complexity.

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?

The schema provides 100% coverage for the single parameter 'name' with enum, default, and description. The tool description does not add parameter-specific details beyond the schema's explanation of scenario keys. Following the baseline rule for high schema coverage, a 3 is suitable.

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 begins with 'Return full details for one preset scenario' which is a specific verb+resource, and it enumerates the exact contents (title, description, teaching note, peak parameters, staffing arrays). It also distinguishes itself from the sibling simulate_scenario by advising to use it before simulating, clearly differentiating its purpose.

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: 'Use this before simulate_scenario to understand the default shape and what overrides make sense.' This provides clear context and a direct alternative/pairing with simulate_scenario, meeting the highest bar for usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the key behavioral trait: it frames each pattern conceptually and points users to ChiAha for custom modeling, which is valuable context 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?

Three sentences: front-loaded purpose with pattern list, usage guidance, and a final note on output style and ChiAha pointer. Every sentence earns its place with no redundancy or filler.

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 zero-input explanation tool with strong annotations, the description fully specifies scope (six patterns), when to use it, and what the output looks like (textbook-level, conceptual framing, ChiAha pointer). No gaps are evident.

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?

The input schema is an empty object with zero parameters, so the baseline of 4 applies. The description correctly avoids mentioning parameters since none exist, and there is no semantic gap.

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 'Return a textbook-level description of six queueing complexity patterns beyond basic M/M/c' and enumerates them. This specific verb+resource distinguishes it from siblings like explain_queueing_theory, making the purpose unambiguous.

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 it ('Use this when the user describes real-world complexity...') with concrete examples. It does not name alternative tools, but the boundary ('beyond basic M/M/c') is clear enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds that the output is ~500 words and covers specified topics, which supplements the structured data 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 entire description is two sentences: the first states the deliverable and content scope, the second gives usage guidance. No filler or redundant phrasings.

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 conceptual explainer with no inputs, the description covers purpose, output length, content areas, and when to use it. Since there is no output schema, the stated '~500-word educational explainer' adequately sets expectations.

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?

The schema has zero parameters and the description explicitly notes 'No inputs,' aligning with the 0-parameter baseline of 4. No additional parameter semantics are needed.

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 opens with 'Return a ~500-word educational explainer of M/M/c queueing theory' and enumerates specific topics (Little's Law, utilization, etc.), clearly distinguishing it from sibling tools that simulate or compare 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?

It explicitly states 'Use this when the user asks a conceptual 'why' or 'how does this work' question' and contrasts with 'rather than asking for a number.' However, it does not name specific sibling tools as alternatives, so it stops one step short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and idempotent, and the description adds valuable behavioral context: 'Pure text computation, no simulation, no RNG — deterministic output,' the educational intent ('TEACH'), and a key limitation ('complexity factors... the M/M/c model can't see'). This goes beyond annotations and is consistent with them.

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 sentences, each serving a distinct purpose: what the tool returns, when to use it, and its deterministic/limitation nature. No redundancy or filler; information is front-loaded and efficiently structured.

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?

Without an output schema, the description fully enumerates the output components ('where you sit on the utilization curve, what ρ means, what one more/fewer server would do, and complexity factors'). It also covers optional parameter behavior and determinism, making it complete for an agent to select and 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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning by linking arrivalRate, serviceRate, and servers to ρ computation and by explaining the optional parameter's behavior: 'If omitted, the tool computes ρ from the inputs and gives a parameter-only interpretation.' This clarifies how parameters influence the output beyond what the schema states.

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 a queueing-theory framed interpretation' for an M/M/c configuration, listing specific output components like utilization curve position and plain-language ρ meaning. It distinguishes itself from siblings by explicitly contrasting with simulation ('no simulation, no RNG') and framing its role as teaching context around a number, not just returning the number.

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 guidance: 'Use this to TEACH while answering — when the user wants context around a number, not just the number itself.' It implies alternatives (simulation tools, theoretical explanations) but does not name specific sibling tools or give explicit when-not-to-use conditions, stopping short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, covering the safety profile. The description adds useful behavioral context beyond annotations: it returns key, title, and one-line description for each of a fixed set of four scenarios, implying deterministic output.

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 resource, and every sentence earns its place. Includes names, return fields, and usage guidance without 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?

For a simple list tool with no parameters, rich annotations, and an output schema, the description fully covers what the tool does, what it returns, and when to use it. No significant gaps.

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?

The tool has zero parameters, so there is nothing to explain. Schema coverage is 100% (vacuously), and the description focuses on output semantics. Baseline 4 is appropriate for parameterless tools.

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 uses a specific verb ('List') and resource ('four pre-built QueueSim scenarios'), and enumerates the exact set (Single Server, Coffee Shop, Grocery Checkout, Call Center). It clearly distinguishes from siblings by directing to describe_scenario for more detail and simulate_scenario to run one.

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 call ('when the user's problem matches one of the preset shapes') and names alternatives for further actions. This provides clear context and differentiation from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses detailed behavioral traits: it runs a binary search over server counts up to maxServers (default 50), invokes the simulator for each candidate, and returns null with achieved wait if even maxServers can't meet the target. It also includes anti-fabrication instructions to quote results verbatim and not propose a different number. These go well beyond the annotations, which only state readOnlyHint and destructiveHint, and do not contradict them.

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 longer than the minimal examples but each sentence serves a clear purpose: purpose, usage guidance, algorithm, infeasibility handling, and anti-fabrication caution. It is structured logically and front-loaded with the core purpose, though the anti-fabrication paragraph adds some length while still being valuable.

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 description covers the tool's algorithm (binary search), its behavior at the maxServers boundary (null with achieved wait), and offers clear guidance on alternative tools. Since an output schema exists, it does not need to describe return values in detail. For a complex inverse simulation tool, this description is remarkably complete.

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?

The description adds meaning to the parameters by explaining that targetAvgWaitMinutes is the maximum acceptable wait and that the tool finds the smallest server count meeting it. It also explains maxServers as the search ceiling. However, schema description coverage is 63%, and the description does not compensate for undocumented parameters like serviceCoV or the distribution enums. It provides moderate added value over 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 the tool's function: 'given an arrival rate, service rate, and a target average wait time, returns the SMALLEST number of servers needed to meet the target.' It uses a specific verb ('returns') and resource ('SMALLEST number of servers'), and explicitly distinguishes it from the sibling tool 'simulate_mmc' by labeling it 'INVERSE of simulate_mmc'. This makes the purpose unmistakable.

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 usage conditions: 'Use this when the user asks "how many servers do I need?" / "what staffing keeps wait under N minutes?"' It also states when not to use it: 'If the user asks "what if c=N?" for a specific N, call simulate_mmc with that c.' This is clear when-to-use and when-not-to-use guidance with a named alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, but the description adds critical behavioral context beyond that: it states that numbers come from a real discrete-event simulation, mandates quoting them verbatim (anti-fabrication), warns against rounding or computing derived figures from training-data recall, and advises re-calling for follow-ups. It also discloses a simulation duration limit (30 days) and directs users for longer studies. This significantly exceeds annotation coverage.

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 appropriately sized—not too long—and front-loaded with the core action. Every sentence adds value: purpose, required inputs, optional inputs, output summary, usage guidance, alternative-tool guidance, and a critical anti-fabrication directive. There is no filler or 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?

Considering the tool's complexity (7 parameters, optional distributions, output summary, and multiple sibling tools), the description covers all necessary aspects: what it does, parameter meaning, output shape, when to use it, and behavioral constraints. The output schema is present, and the description doesn't need to explain return values in detail. The anti-fabrication and simulation-time limits round out a complete picture.

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?

The schema has 100% parameter description coverage with detailed descriptions, including units and ranges. The description restates the key params (λ, μ, c) and mentions optional ones, but it does not add substantive meaning beyond what the schema already provides. Baseline of 3 is appropriate given the schema's completeness.

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 opens with a specific verb and resource: 'Run a generic M/M/c queue simulation.' It clearly lists required inputs (arrival rate, service rate, server count) and outputs, and explicitly distinguishes itself from siblings by calling itself 'the primary tool' for staffing/average-wait questions and preferred over simulate_scenario for flat-number what-if questions.

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 guidance: it is the primary tool for 'how many servers do I need?' and 'what's my average wait?' questions, and it names an alternative (simulate_scenario) with a clear rule for when to prefer this tool instead. It also instructs to pull peak params from describe_scenario, giving concrete usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite readOnlyHint=true annotations, the description adds crucial behavior: overrides apply uniformly, closed hours stay zero, and results come from a real simulation requiring verbatim quoting. 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?

Although lengthy, each section earns its place: purpose, usage boundaries, and anti-fabrication rules. Front-loaded with core function and scannable guidance.

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 rich annotations and output schema. It covers behavioral semantics, alternative tool selection, and critical output fidelity instructions. No gaps.

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 already covers all parameter fields, but description explains the overrides object's uniform application semantics, replacing patterns like 4/6/4 with flat values—something schema cannot capture. This adds meaningful value beyond field 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?

Description opens with a specific verb ('Run') + resource ('preset scenarios') + enumerates the scenarios and overrides. It also distinguishes itself from simulate_mmc, clarifying its unique 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 states when to use (faithful reproduction or uniform scaling) and when not to use (per-hour tweaks), and points to simulate_mmc as alternative. This is exemplary guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly and non-destructive, but the description adds critical behavioral context: numbers come from a real DES run and must be quoted verbatim without rounding or estimation. It also explains the terminating-system effect of using 0, which is not in 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?

The description is a moderately long paragraph, but it is front-loaded with the purpose and every sentence serves a role: example, inputs, closed-hours rule, return shape, alternatives, and anti-fabrication. Slightly dense but not wasteful.

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?

An output schema exists, so return details need not be spelled out. The description provides usage context, alternatives, behavioral constraints, and the per-hour variation emphasis, making it complete for the tool's complexity.

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%, and the description mostly restates schema descriptions for arrivalRates, staffing, and serviceTimeMinutes. It adds little beyond 'Use 0 in both arrays for closed hours,' which the schema already mentions. Distribution parameters are left to 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 opens with a specific verb+resource: 'Run a queueing simulation against an arbitrary 24-hour staffing schedule.' It clearly distinguishes the tool from siblings by emphasizing custom day shapes and explicitly comparing to simulate_scenario and simulate_mmc.

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?

It gives an explicit trigger: 'Take this when the user describes a custom day shape that doesn't match a preset,' with a concrete example. It also names alternatives and indicates when each is a stronger fit, plus the closed-hours convention.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.