Exact staffing math: FTE needed, a monthly hiring plan, and Erlang C queue staffing.
Scored across 3 tools
Each tool has a clearly distinct purpose: Erlang C for live queue staffing, month-by-month hiring/ramp planning, and steady-state FTE sizing. The descriptions explicitly route between them (required_fte says use hiring_plan when volume changes, use erlang_staffing for answer-time targets), leaving little room for misselection.
All names are snake_case and concise, but they mix shapes: erlang_staffing (method_noun), hiring_plan (noun_noun), required_fte (adjective_noun). There is no verb_noun pattern, though the domain-noun style is still readable and predictable within this small set.
Three tools is well-scoped for a narrow workforce-math server; each covers a genuinely different calculation mode (queue, steady FTE, growth/hiring). Nothing feels padded or redundant.
The core lifecycle — size FTE, staff a live queue, project hiring over time — is covered, including shrinkage and ramp handling. Minor gaps remain: no cost/budget calculation, no shift/schedule generation despite mentioning 'people to schedule', and no reverse lookup of service level for a fixed headcount as a standalone tool.
Agents needed on a live queue (phone, chat) to answer a target share of contacts within a target time, using Erlang C. Give contacts per hour for the interval being staffed (usually the busiest hour) and handle time in seconds. Returns agents needed, the service level at that number and at one fewer, chance of waiting, occupancy, and people to schedule after shrinkage. Use required_fte for case or ticket work with no answer-time target.
| Name | Required | Description | Default |
|---|---|---|---|
| shrinkage | No | Share of paid time agents are off the queue. Converts agents to people scheduled. Default 0.3. | |
| service_level | No | Share of contacts to answer within the target time. Default 0.8. | |
| contacts_per_hour | Yes | Contacts arriving per hour in the interval being staffed. | |
| handle_time_seconds | Yes | Average handle time in seconds: talk plus after-contact work. | |
| answer_within_seconds | No | Target answer time in seconds. Default 20. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| steps | Yes | |
| agents | Yes | |
| answer | Yes | |
| engine | Yes | |
| inputs | Yes | |
| occupancy | Yes | |
| people_to_schedule | Yes | |
| offered_load_erlangs | Yes | |
| probability_of_waiting | Yes | |
| service_level_at_agents | Yes | |
| service_level_one_fewer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds what the computation returns (service level at n and n-1, wait probability, occupancy, shrinkage-adjusted headcount), which conveys that this is a sensitivity-producing calculation rather than a single number. It does not mention edge behavior such as what happens at very low load or invalid target/service-level combinations, so it adds only modest context beyond the structured fields and the output schema.
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 with the purpose, then inputs, then outputs, then the sibling exclusion. Nothing is redundant and no sentence could be dropped without losing 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?
For a read-only calculation tool with a full input schema and an output schema, the description supplies everything an agent needs: what it computes, how to parameterize the inputs, what comes back conceptually, and when to prefer the sibling.
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 the baseline is 3. The description still earns credit by adding interpretation the schema lacks: that contacts_per_hour should represent the busiest interval being staffed, that shrinkage converts agents into people to schedule, and that answer-time targets are optional in spirit for non-queue work.
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?
States a specific computation (agents needed) on a specific resource (live phone/chat queue) with the method named (Erlang C), and explicitly distinguishes itself from the sibling required_fte for case/ticket work with no answer-time target.
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?
Gives the condition to use it (live queue with a target share answered within a target time), the input heuristic (contacts per hour for the busiest hour), and names the alternative when there is no answer-time target. The routing decision is fully determined from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Month-by-month hiring plan: how many requisitions to open each month so FTE on hand keeps up with FTE needed, after attrition, time to hire and ramp. Give weekly_volume with monthly_growth (0.05 means 5% a month, compounding), or weekly_volume_by_month. Unknown inputs fall back to stated defaults: current headcount defaults to what month 1 needs, attrition to 0, time to hire to 2 months, ramp to 0. When attrition is assumed, the result also gives the plan at 15% and 30%. Give hires_in_flight for people already hired or in the pipeline. Returns the plan table, totals, the arithmetic, and which inputs were assumed. A hire counts as zero capacity until fully ramped.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | Plan length in months when using monthly_growth. Default 12. | |
| shrinkage | No | Share of paid time not available for the work: PTO, sick time, training, meetings. 0.30 means 30%. Default 0.3. | |
| ramp_months | No | Months from start date to full productivity. Default 0. | |
| start_month | No | First month of the plan as YYYY-MM, used only to label months. | |
| weekly_volume | No | Weekly volume in month 1. Use with monthly_growth. | |
| monthly_growth | No | Month-over-month change in weekly volume. 0.05 means 5% a month. Default 0. | |
| hires_in_flight | No | People already hired or in the pipeline, and the month they start counting. These are the only way to cover months before a new requisition can land. | |
| annual_attrition | No | Share of the team that leaves in a year. 0.25 means 25%. Default 0. | |
| minutes_per_case | Yes | Average handling time per case, in minutes. | |
| target_occupancy | No | Share of available time you plan to keep people busy with the work. Default 0.85. | |
| current_headcount | No | FTE on the team today. Default: what month 1 needs, rounded up. | |
| hours_per_fte_week | No | Paid hours per full-time person per week. Default 40. | |
| time_to_hire_months | No | Months from opening a requisition to the start date. Default 2. | |
| weekly_volume_by_month | No | Average weekly volume in each month of the plan, instead of weekly_volume and monthly_growth. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| steps | Yes | |
| answer | Yes | |
| engine | Yes | |
| inputs | Yes | |
| months | Yes | |
| most_spare | Yes | |
| total_reqs | Yes | |
| attrition_range | Yes | |
| expected_leavers | Yes | |
| lookahead_months | Yes | |
| months_with_spare | Yes | |
| fte_needed_last_month | Yes | |
| fte_needed_first_month | Yes | |
| first_month_hires_can_count | Yes | |
| months_short_before_hires_land | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, idempotent, closed-world computation, so the description's burden is lower, and it still adds real behavior: unknown inputs fall back to stated defaults, the response is accompanied by a 15% and 30% attrition sensitivity, and it reports which inputs were assumed. The rule that a hire counts as zero capacity until fully ramped is a genuinely useful behavioral disclosure. It does not cover runtime characteristics such as compute cost or limits on large month arrays.
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?
Purpose is front-loaded in the first sentence, followed by input-mode selection, defaults, sensitivity behavior, and return contents in a logical order with no filler. It is dense but appropriately so for a 14-parameter planning model; only minor tightening would help.
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 14-parameter computational tool with annotations and an output schema, the description covers the ambiguity an agent would actually hit: default resolution, the two mutually exclusive volume modes, pipeline hires, ramp treatment, and what the response contains. The remaining gap is the absent relationship to its sibling tools.
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 the baseline is 3; the description earns above that by explaining the interplay of parameters rather than repeating them — monthly_growth is stated to be compounding, current_headcount defaults to month 1's requirement rounded up, and hires_in_flight is framed as the only way to cover months before a new requisition can land. It stays silent on shrinkage, target_occupancy, and hours_per_fte_week, but those are documented in 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 opening sentence names the resource and the computed output precisely: month-by-month requisitions to open so FTE on hand tracks FTE needed after attrition, time to hire, and ramp. That is far more specific than a tautology. It does not, however, distinguish itself from the siblings required_fte and erlang_staffing, so an agent must infer which of the three to pick.
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?
Guidance is given on how to drive the model (supply weekly_volume with monthly_growth, or weekly_volume_by_month; use hires_in_flight for people already hired) and on default fallbacks for unspecified inputs. What is missing is when-to-use-this-vs-alternatives: no sibling is named and no exclusion is stated, so routing among required_fte, erlang_staffing, and this tool is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many people a steady workload needs. Give weekly volume and minutes per case; shrinkage, target occupancy and hours per week fall back to stated defaults. Returns FTE, people to staff (rounded up), every input marked given or assumed, and the arithmetic with numbers filled in. Use hiring_plan when volume changes over time or the question is about hiring, and erlang_staffing for live queues with an answer-time target.
| Name | Required | Description | Default |
|---|---|---|---|
| shrinkage | No | Share of paid time not available for the work: PTO, sick time, training, meetings. 0.30 means 30%. Default 0.3. | |
| weekly_volume | Yes | Cases, tickets or items arriving per week. | |
| minutes_per_case | Yes | Average handling time per case, in minutes. | |
| target_occupancy | No | Share of available time you plan to keep people busy with the work. Default 0.85. | |
| hours_per_fte_week | No | Paid hours per full-time person per week. Default 40. |
| Name | Required | Description |
|---|---|---|
| fte | Yes | |
| notes | Yes | |
| steps | Yes | |
| answer | Yes | |
| engine | Yes | |
| inputs | Yes | |
| people | Yes | |
| weekly_work_hours | Yes | |
| fte_per_extra_minute | Yes | |
| planned_hours_per_fte_week | Yes | |
| productive_hours_per_fte_week | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful context about defaults and the returned arithmetic, but it does not go much beyond what the annotations and output schema already establish.
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 the purpose, then inputs/defaults, then return values, then alternatives. Every sentence is useful and there is no redundant wording.
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 and annotations, the description is complete enough for an agent to select and invoke the tool correctly. It covers purpose, required inputs, defaults, return shape, and sibling alternatives.
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 the schema already documents all five parameters, including defaults and ranges. The description reinforces which inputs are required and which fall back to defaults, but adds little semantic detail 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 states a specific computation: how many people a steady workload needs from weekly volume and minutes per case. It clearly scopes the tool to steady workloads, which distinguishes it from the sibling tools.
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 names when to use the alternatives: hiring_plan for changing volume or hiring questions, and erlang_staffing for live queues with an answer-time target. It also tells the caller which inputs to provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
erlang_staffinghiring_planrequired_fteBuilds optimal 24/7 staff rosters with a real MILP solver: rest rules, skills, nights, fairness.
Healthcare staffing simulator — ED, walk-in clinic, and appointment office DES tools.
Capacity benchmarks, capacity math and Portable Delivery Intelligence for marketing agencies.
Employee scheduling, staffing feasibility, localized demos, schedule reports and CSV export.
Add one secure layer between your agents and this server.
