Assembled

Create one or more forecast adjustments layered on the master forecast. Each adjustment applies an 'add' or 'multiply' operation to the forecasted contact volume over a time range, optionally scoped to a single queue. Use this when the user wants to manually raise or lower the forecast (e.g. anticipating a marketing campaign, a holiday bump, or correcting a known under-forecast).

create_forecast_adjustments

Publish one overtime ('OT') or voluntary-time-off ('VTO') slot.

create_overtime_and_vto

Get BPO staffing per time bucket: required, committed, scheduled and actuals. Same numbers as the BPO requirements heatmap in the app. Buckets use the company's smallest configured vendor requirement interval (returned as `interval`, in seconds) and are in UTC. Values are heads: the average number of agents working during the bucket. Heads add up across queues, sites and channels within a bucket, but not across buckets; average them over time (or multiply by the bucket length in hours to get agent-hours). - required / committed: uploaded by the BPO; null when nothing was uploaded for that bucket. - scheduled: productive time on the schedule (`schedule_id`, or the master schedule when omitted). - actuals: in-adherence time from cached metrics; null for future buckets and partial for today. Compare scheduled or actuals against required to find under- or over-staffed intervals.

get_bpo_heatmap

Get agent state rows (what state each agent was in on connected platforms, e.g. online/away/on-ticket) over a time window. Two modes: - Company-wide export (agent_id omitted): rows for all agents matching the optional filters. With priority_order set, the condensed timeline is used: one row per agent per time segment, deduped across platforms by your priority order and with adjacent same-state rows merged. Without it, raw per-platform rows that may overlap in time. Prefer the condensed timeline when summing time in state (e.g. online / occupied / productive hours for a custom formula), since raw rows can double-count overlapping platforms. - Per-agent (agent_id set): cursor-paginated rows for one agent. Responses are bounded: at most 500 rows per call (default 100), a 1-day window company-wide, and a 31-day window per agent. Raw state data is dense (one row per state change per platform), so narrow with filters or platforms and paginate rather than widening the window.

get_agent_states

Get scheduled activities for agents matching a filter over a small time window. Use this when the user asks who is scheduled, what coverage looks like for a queue, or what an agent's day looks like. Returns the schedule as it currently is; `start_time` / `end_time` filter on when activities take place. For who changed an agent's schedule or when a shift was moved, use get_schedule_history. Required scoping ---------------- At least one of `queue`, `site`, `team`, or `skill` MUST be set; `channel` alone is rejected. To resolve a user-facing name to an external ID, call `get_workforce_config()` first and match on the appropriate `*[].name`. If nothing matches, ask the user to clarify rather than guessing. If the server rejects the request with 400, the rejection details from the upstream JSON body — `agent_count`, `filters_applied`, `tier_caps`, and a `suggested_action` string — arrive as keys on `error` itself; a non-JSON rejection arrives as text in `error["error"]` instead. **Read `suggested_action` and follow it verbatim on retry rather than guessing permutations.**

get_schedule

Get the current date and time, in both UTC and the company's timezone. Call this before constructing any date range from a relative phrase ("today", "yesterday", "last week", "last 30 days"). Use the company-local date so a "day" matches the Assembled UI. Do not guess the current date from memory — it is likely about a year out of date.

get_current_time

List existing forecast adjustments for the company. Forecast adjustments are manual overrides layered on top of the master forecast. Each adjustment has an operation ('add' or 'multiply') and a value applied over a time range for a given channel (and optionally queue).

get_forecast_adjustments

Get forecasted vs actual comparison metrics from Assembled. Returns bucketed comparisons of forecasted vs actual values for a given channel (and optional queue) over the requested time range. This covers volume (contacts/cases), handle time, service level, staffing (required/scheduled/net) and related metrics. Use this tool when the user wants to understand how actuals compared to the forecast, rather than raw forecasts alone. Volume is reported under different fields depending on the company's metrics configuration: `contacts_received` (and `cases_opened`) for legacy companies, or `case_volume` and `units_of_work` for companies on the newer metrics configuration. When both `case_volume` and `units_of_work` are present, the channel's configured contact input (case volume or units of work) determines which one the forecast is built on, and that setting is not included in this response. Report both and name the field you are quoting rather than presenting either as the single "volume" number. The bucket interval and schedule are chosen automatically: bucket size is picked from the window length (15m for <1 day, 1h for 1 day to 1 week, 1 day for >1 week) and the company's master schedule is always used. These are intentionally not exposed as tool arguments. Windows longer than ~6 months (184 days) are rejected: forecasted vs actual is intended for operational analysis. For year-plus historical trend analysis, use the analytics/metrics tool instead, or split the question into several shorter windows and call this tool per window.

get_forecasted_vs_actual

Get the catalog of available metrics and instructions for using the query_metrics() tool. Use this to determine available namespaces, metrics, and dimensions.

get_metrics_catalog

List existing overtime ('OT') and voluntary-time-off ('VTO') slots. Use this before posting a new OT/VTO offer to avoid duplicates, or to verify uptake on a slot you previously posted (capacity vs. how many agents have opted in). Each row includes 'remaining_capacity = max(0, abs(capacity) - num_approved_requests)' as a derived convenience — the number of additional agent opt-ins the slot can still accept. Works for both OT (positive capacity) and VTO (negative capacity); remaining_capacity is None for uncapped slots.

get_overtime_and_vto