How do I use cxone-wfm-intraday-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cxone-wfm-intraday-mcp Which queues are at risk right now?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cxone-wfm-intraday-mcp

by ssolanky

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

CXone WFM Intraday MCP (Sparkathon Prototype)

An MCP server that exposes governed CXone WFM Intraday tools to an AI assistant. It proves one Real-Time Analyst workflow — "Why is Billing Support at risk today, and what can we do to recover SLA?" — grounded entirely in structured tool calls over deterministic synthetic data. Simulation only; no live systems, no write-back.

Design spec: docs/superpowers/specs/2026-07-15-cxone-wfm-intraday-mcp-design.md.

Tools

Tool	Purpose
`list_intraday_metrics`	Catalog of queryable Intraday metrics
`resolve_intraday_entity`	Fuzzy name → canonical queue
`get_intraday_snapshot`	Current state of all/selected queues + highest-risk queue
`get_forecast_vs_actual`	Per-interval forecast vs actual variance
`get_intraday_risk_drivers`	Ranked reasons a queue is at risk
`get_available_capacity`	Donor queues with spare capacity + trade-offs
`simulate_recovery_action`	Before/after impact of moving N agents for Y minutes
`summarise_intraday_recommendation`	Plain-English what / why / action / impact / trade-offs
`load_intraday_data`	Replace the dataset with your own queues (bring-your-own-data)
`reset_intraday_data`	Restore the built-in demo dataset

Related MCP server: Deputy Workforce Operations MCP

Ways to run it

Pick the path that fits — all three end with the same 10 tools available to your assistant:

Fastest, no install → Quick start (uv): one uvx command, nothing to clone.
Local dev / offline / to change the data → Setup: clone + venv + pip install.
Share via a URL (teammates install nothing) → Run as a remote HTTP MCP: deploy to Cloud Run.

Then, in your assistant, ask "Which queues are at risk right now?" and follow the Demo script.

Quick start (no clone, via uv)

If you have uv installed and access to this repo, register the server with a single command — no git clone, no venv, no pip install. uv fetches, installs, and runs it in an ephemeral environment straight from the repo.

Claude Code:

claude mcp add cxone-wfm-intraday -- uvx --from git+https://github.com/ssolanky/cxone-wfm-intraday-mcp cxone-wfm-intraday

Claude Desktop — add to claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "cxone-wfm-intraday": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/ssolanky/cxone-wfm-intraday-mcp", "cxone-wfm-intraday"]
    }
  }
}

Notes: this is a local server — uv runs it on your machine, it just removes the manual clone/install steps. Because the repo is private, uv needs Git access to it (a credential helper via gh auth setup-git, or a token). No uv? Use the full Setup below instead.

Setup

git clone https://github.com/ssolanky/cxone-wfm-intraday-mcp.git
cd cxone-wfm-intraday-mcp
python -m venv .venv
# Windows:  .venv\Scripts\activate       macOS/Linux:  source .venv/bin/activate
python -m pip install -e ".[dev]"
python -m pytest -q          # all tests should pass (64 tests)

NICE machines: pip here defaults to a private CodeArtifact index that 401s and lacks mcp. Install from public PyPI instead: python -m pip install --index-url https://pypi.org/simple/ -e ".[dev]" (or add index-url = https://pypi.org/simple/ under [global] in .venv/pip.ini).

Run against Claude

Claude Code:

claude mcp add cxone-wfm-intraday -- python -m cxone_wfm_intraday_mcp.server

(run from this project directory, using the interpreter where the package is installed).

Claude Desktop: copy the block from claude_desktop_config.example.json into your claude_desktop_config.json (Settings → Developer → Edit Config), fixing command to your Python interpreter, then restart Claude Desktop.

Run as a remote HTTP MCP (optional)

The same server can serve the Streamable HTTP transport instead of stdio, so teammates add just a URL — nothing installed locally. It's zero config: the server serves HTTP automatically when a PORT env var is present (as on Google Cloud Run) or MCP_TRANSPORT=http is set, and otherwise stays stdio for local use. HTTP endpoint path is /mcp.

Test it locally:

# macOS/Linux
MCP_TRANSPORT=http PORT=8080 python -m cxone_wfm_intraday_mcp.server
# Windows PowerShell
$env:MCP_TRANSPORT="http"; $env:PORT="8080"; python -m cxone_wfm_intraday_mcp.server
# now serving at http://127.0.0.1:8080/mcp

Deploy to Google Cloud Run (free tier, scales to zero) — from the repo root, using the included Dockerfile:

gcloud run deploy cxone-wfm-intraday --source . --region <region>

Cloud Run builds the image, injects PORT, and the server serves HTTP automatically. It prints a service URL; register it with any assistant:

claude mcp add --transport http cxone-wfm-intraday https://<service-url>/mcp

Auth: a public URL serving even mock data should be protected. Cloud Run requires IAM auth by default (omit --allow-unauthenticated); for other hosts put a token/proxy in front. Authentication was deliberately deferred by the Sparkathon spec — add it before any non-demo use.

Demo script

"Which queues are at risk right now?" → snapshot flags Billing Support.
"Why is Billing Support at risk?" → volume +18%, AHT +11%, staffing −3.
"What can we do to recover?" → move 2 agents from General Enquiries.
"What would the impact be?" → SLA 72% → ~81%, General Enquiries stays above target.

What you can ask (and what you'll get back)

You never call tools by name — just ask in plain language and the assistant picks the right tool(s). The tables below list example prompts, the tool(s) that fire, and the answer you can expect on the built-in demo data (swap in your own data and the same questions work — see Bring your own data).

Reading current state

Ask something like…	Tool(s)	Expected answer (demo data)
"What metrics can I query?" / "What data do you have?"	`list_intraday_metrics`	The 11 Intraday metrics with definitions/units: SLA, SLA target, forecast/actual volume, forecast/actual AHT, planned/actual staffing, occupancy, backlog, risk status.
"Which queues are at risk right now?" / "Give me the intraday snapshot"	`get_intraday_snapshot`	All 5 queues with SLA/target, volume, AHT, staffing, occupancy, backlog, risk — and highest risk: Billing Support (72% vs 80% target).
"How is Sales doing?" / "Show me just Billing and General Enquiries"	`resolve_intraday_entity` → `get_intraday_snapshot`	The selected queue(s) only. Sales → 83% vs 80% target, watch.
"Does 'GE' / 'the billing queue' / 'tech support' map to a real queue?"	`resolve_intraday_entity`	Resolves fuzzy names/aliases → General Enquiries / Billing Support / Technical Support (with a confidence level).

Explaining risk

Ask something like…	Tool(s)	Expected answer (demo data)
"Why is Billing Support at risk?"	`resolve_intraday_entity` → `get_intraday_risk_drivers`	Primary: volume +18% above forecast. Also AHT +11%, staffing 3 below plan, occupancy 92%, backlog 47. Severity: high.
"How are actuals tracking vs forecast for Billing this morning?"	`get_forecast_vs_actual`	Six 30-min intervals (08:00–10:30); variance widens from ~0% to +18% volume / +11% AHT, staffing drifts 15 → 12.
"Which queue is under the most pressure and why?"	`get_intraday_snapshot` → `get_intraday_risk_drivers`	Billing Support, driven by the volume spike + AHT + staffing gap (as above).

Finding capacity & recovering

Ask something like…	Tool(s)	Expected answer (demo data)
"Is there spare capacity to help Billing?" / "Who can lend agents?"	`get_available_capacity`	General Enquiries can spare 2 (SLA 94% → ~92%, still above target); Complaints can spare 1. Sales & Technical Support: none (staffed to plan).
"What's the best recovery action?" / "How do we recover Billing's SLA?"	`summarise_intraday_recommendation`	Move 2 agents from General Enquiries to Billing Support for 60 min → Billing SLA 72% → ~81.2%, GE stays above target. Trade-off + "monitor AHT and backlog" included.
"What happens if I move 2 agents from General Enquiries to Billing for 60 minutes?"	`simulate_recovery_action`	Billing 72% → 81.2% (occupancy 92 → 79); GE 94% → 91.9% (occupancy 71 → 81), stays above its 80% target; no new risk.
"What if I move 3 instead?"	`simulate_recovery_action`	Billing → 84.6%, GE → 90.6% — but flagged: 3 exceeds GE's spare capacity of 2, so GE drops below its own plan.
"Can I pull 2 from Sales instead?"	`simulate_recovery_action`	Billing → 81.2%, but Sales falls 83% → ~71%, below its 80% target — not a safe donor (risk created).

Bring-your-own-data & housekeeping

Ask something like…	Tool(s)	Expected answer
"Load this intraday data, then tell me which queue is at risk: `{…}`"	`load_intraday_data`	"Loaded N queues; highest risk: `<id>`." Every later question then analyzes your data.
"Reset to the demo data"	`reset_intraday_data`	Restores the built-in 5-queue demo for your session.

A full worked conversation (demo data)

You: Which queues are at risk right now? Assistant: Five queues are live. Billing Support is the highest risk — SLA 72% against an 80% target. General Enquiries (94%), Technical Support (88%) and Complaints (91%) are healthy; Sales (83%) is on watch.
You: Why is Billing Support at risk? Assistant: Three things are compounding: volume is 18% above forecast, AHT is 11% higher than expected, and staffing is 3 agents below plan — pushing occupancy to 92% with a backlog of 47. The variance has widened steadily since 08:00.
You: What can we do to recover? Assistant: General Enquiries has 2 agents of spare capacity (it's 2 over plan at 94% SLA). Complaints could lend 1; Sales and Technical Support have none.
You: What would moving 2 from General Enquiries do? Assistant: Billing Support SLA improves from 72% to ~81.2% and its occupancy eases from 92% to ~79%. General Enquiries dips to ~91.9% — still comfortably above its 80% target. No new risk is created. Recommend the move for 60 minutes and keep watching AHT and backlog.

When something's off (error responses)

Ask something like…	What you'll get
"Analyze the Refunds queue"	An error naming the valid queues: "Could not resolve 'Refunds'… Valid queues: Billing Support, Complaints, General Enquiries, Sales, Technical Support."
"Move 50 agents from General Enquiries to Billing"	"Cannot move 50 agents from General Enquiries; only 16 are staffed."
Loading data with a missing/invalid field	A clear message (e.g. "queue 'x': missing required field 'sla_current'" or "risk_status must be one of ('at_risk','watch','healthy')"), and the current dataset is left untouched.

Where the data comes from

All data is synthetic and hardcoded in cxone_wfm_intraday_mcp/data.py — a fixed in-memory list of 5 queues loaded once at startup. There is no database, API, CXone tenant, network call, or randomness, so every run returns identical numbers (a repeatable demo by design). This matches the spec: for the prototype, mocked data is acceptable; the point is proving the pattern of grounded, tool-driven answers.

What's stored by hand vs. computed at call time:

Stored (the demo "facts"), per queue in data.py: sla_current, sla_target, volume_actual/forecast, aht_actual/forecast, staffing_planned/actual, occupancy, backlog, a risk_status label (at_risk / watch / healthy), and a 6-interval forecast-vs-actual history.
Computed from those stored fields at call time — this is the real "analysis":
- get_intraday_snapshot ranks queues by stored risk_status (analysis.py).
- get_forecast_vs_actual / get_intraday_risk_drivers compute volume/AHT/staffing variance from the stored actual-vs-forecast values and flag drivers over thresholds (analysis.py).
- get_available_capacity derives spare agents (surplus over plan, validated against the SLA curve).
- simulate_recovery_action recomputes SLA for both queues via the formula below (simulation.py).

So "Billing Support is at risk" is a hand-authored label, but "…because volume is +18%, AHT +11%, staffing −3, and moving 2 agents lifts SLA 72→81.2%" is genuinely calculated from the stored fields — never invented by the assistant.

Change the scenario (make a different queue at risk, tweak SLA/volume/staffing, add a queue) by editing the literals in data.py — nothing else needs to change. In a real product, data.py would be replaced by live CXone WFM as the source of truth; the tool contracts stay identical.

Bring your own data

Consumers can analyze their own Intraday data without editing any code, via two tools:

load_intraday_data — replace the dataset with your own queues; every other tool then analyzes your data.
reset_intraday_data — restore the built-in demo.

Just ask the assistant (e.g. "Load this Intraday data and tell me which queue is at risk") and provide queues shaped like:

{
  "queues": [
    {"id": "payments", "name": "Payments", "sla_current": 64, "sla_target": 85,
     "volume_forecast": 200, "volume_actual": 260, "aht_forecast": 280, "aht_actual": 320,
     "staffing_planned": 18, "staffing_actual": 14, "occupancy": 94, "backlog": 40,
     "risk_status": "at_risk", "aliases": ["pay"]},
    {"id": "onboarding", "name": "Onboarding", "sla_current": 97, "sla_target": 80,
     "volume_forecast": 90, "volume_actual": 80, "aht_forecast": 300, "aht_actual": 290,
     "staffing_planned": 7, "staffing_actual": 10, "occupancy": 55, "backlog": 0,
     "risk_status": "healthy"}
  ]
}

Per-queue fields: id, name, sla_current, sla_target, volume_forecast, volume_actual, aht_forecast, aht_actual, staffing_planned, staffing_actual (≥ 1 — the SLA curve divides by it), occupancy, backlog, risk_status (at_risk | watch | healthy). Optional: aliases (list) and intervals (list of {interval, volume_forecast, volume_actual, aht_forecast, aht_actual, staffing_planned, staffing_actual}). Percentages are 0–100, times are seconds, staffing is agent counts. Invalid input is rejected with a clear message and leaves the current dataset untouched.

Isolation: loaded data is scoped to your MCP session — on a shared HTTP server each conversation gets its own dataset (one client's load never affects another). reset_intraday_data, or the session ending, restores the demo for that session only. stdio has a single session (just you). Nothing is persisted to disk; the dataset lives in memory for the life of the session.

The simulation model

Rule-based and deterministic. Each queue has a staffing→SLA response curve sla(n) = 100 − (100 − sla_current)·decay^(n − staff_actual), with decay = exp(−2.4 / staff_actual), anchored so sla(actual) = current SLA. Every number the assistant reports comes from this formula given tool inputs — not from the model's own reasoning. See §6 of the design spec.

Available Tools

10 tools

get_available_capacityC

Identify queues with spare capacity that could help recover the target queue.

ParametersJSON Schema

Name	Required	Description	Default
`target_queue`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as permissions, side effects, rate limits, or whether the operation is read-only. It only states the purpose, leaving the agent uninformed about important behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but not structured. It does not waste words but also fails to provide any supplementary information beyond the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description is incomplete. It does not explain what the tool returns (e.g., list of queue names, capacity metrics) or how to interpret the results, which is essential for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the parameter 'target_queue', and the tool description adds no additional meaning or format guidance. The agent receives no clarity on what values are valid or what 'target_queue' refers to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'identify' and the resource 'queues with spare capacity', with the specific purpose of helping recover the target queue. It distinguishes itself from siblings like 'get_forecast_vs_actual' or 'simulate_recovery_action', which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any conditions or constraints. There is no explicit advice on when to avoid using it or which sibling might be more appropriate.

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

get_forecast_vs_actualC

Return per-interval forecast vs actual volume, AHT, and staffing for a queue.

ParametersJSON Schema

Name	Required	Description	Default
`queue`	Yes
`intervals`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose any behavioral traits such as read-only status, authentication needs, or side effects. The description is minimal and does not add context beyond the obvious function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it lacks structure. It is too brief to provide sufficient information, making it less effective despite being short.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and a minimal description, the tool definition is incomplete. It does not explain return values, interval details, or edge cases, leaving the AI agent with insufficient context to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning no descriptions for parameters. The description does not explain the 'intervals' parameter (e.g., format, meaning) or the 'queue' parameter's expected format. It only loosely implies queue is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return' and the resource 'per-interval forecast vs actual volume, AHT, and staffing for a queue'. It distinguishes from sibling tools like get_available_capacity by focusing on forecast vs actual comparisons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_intraday_metrics or get_available_capacity. The description does not mention prerequisites or usage context.

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

get_intraday_risk_driversC

Explain why a queue is at risk: ranked risk drivers with supporting data.

ParametersJSON Schema

Name	Required	Description	Default
`queue`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behaviors. It fails to mention side effects, permissions, or limitations. For a read analysis, it should indicate no destructive actions, but does not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, efficient and front-loaded. However, it could add a bit more detail without becoming verbose, such as indicating the output structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and no annotations, the description is too minimal. It lacks details on return values, prerequisites, or how the risk drivers are derived, making it incomplete for reliable agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The only parameter 'queue' is mentioned in the description but without additional meaning (e.g., format, example, or constraints). The description does not compensate for the lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'explain' and the resource 'queue', with an outcome 'ranked risk drivers with supporting data'. It distinguishes itself from sibling tools like 'get_intraday_snapshot' by focusing on risk explanation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives (e.g., 'get_intraday_snapshot'). There is no mention of context or exclusions, leaving the agent to infer usage.

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

get_intraday_snapshotC

Return current Intraday state for all (or selected) queues and the highest-risk queue.

ParametersJSON Schema

Name	Required	Description	Default
`queues`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It describes a read operation ('return') but does not mention whether it is read-only, any side effects, permissions needed, or data freshness guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core functionality without superfluous words. It is efficient, though slightly more detail could improve clarity without adding length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 1 parameter, no output schema, and a vague description, the tool definition leaves out critical details: what constitutes 'state', how 'highest-risk' is determined, and what the return format looks like. This incompleteness hampers correct agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the single parameter 'queues'. The description adds meaning by stating 'for all (or selected) queues', which clarifies its purpose, though it does not specify the format of queue identifiers or the effect of null.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns 'current Intraday state' for queues and the highest-risk queue, with a specific verb and resource. It distinguishes itself from sibling tools like 'get_intraday_risk_drivers' by focusing on a snapshot of state rather than risk details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or context for selecting 'all or selected queues'.

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

list_intraday_metricsB

List the Intraday metrics available to query, with definitions and units.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior1/5

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

No annotations are provided, and the description lacks any behavioral details such as side effects, permissions, rate limits, or reliability. For a listing tool, even basic read-only hints are absent, making it opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that conveys the core function without extraneous words. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no parameters, the tool lacks an output schema, and the description only vaguely indicates the output contains definitions and units. The agent lacks sufficient context about the return format, which is critical for further processing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and schema coverage is 100%, so the description cannot add parameter semantics. The baseline for zero parameters is 4; the description mentions 'definitions and units,' which is about output, not parameters, so no deduction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists available intraday metrics with definitions and units. The verb 'List' and the resource 'Intraday metrics' are specific, and it distinguishes itself from sibling tools which are more about data retrieval or actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like get_available_capacity or get_intraday_snapshot, leaving the agent without context for optimal selection.

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

load_intraday_dataA

Replace the Intraday dataset with the user's own queues, so every other tool analyzes THEIR data instead of the built-in demo.

Each queue object requires: id, name, sla_current, sla_target, volume_forecast, volume_actual, aht_forecast, aht_actual, staffing_planned, staffing_actual (>= 1), occupancy, backlog, risk_status ("at_risk" | "watch" | "healthy"). Optional: aliases (list of strings) and intervals (list of objects with interval, volume_forecast, volume_actual, aht_forecast, aht_actual, staffing_planned, staffing_actual). Percentages are 0-100; times are seconds; staffing is agent counts.

Note: this sets the dataset for the whole server process, not per-conversation. Call reset_intraday_data to restore the demo dataset.

ParametersJSON Schema

Name	Required	Description	Default
`queues`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Since no annotations are present, the description carries the full burden. It discloses that the tool 'sets the dataset for the whole server process, not per-conversation' and mentions the restorative sibling, which is good. However, it could explicitly state that it overwrites existing data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat lengthy due to the detailed parameter specification, which is necessary. However, it is front-loaded with the main purpose and well-structured. Still, it could be more concise by moving parameter details to a structured example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema and the input is complex, the description covers all necessary context: what the tool does, how it affects other tools, how to restore the default, and the exact structure of the input data. No additional explanations are needed for an agent to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for properties, but the description provides a comprehensive specification: required fields, optional fields, data types (list of strings, objects), and constraints (percentages 0-100, times in seconds, staffing counts). This fully compensates for the schema's lack of detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Replace the Intraday dataset with the user's own queues', using a specific verb and resource. It also distinguishes itself from sibling tools like reset_intraday_data by explaining that this loads custom data while that restores demo data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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: 'so every other tool analyzes THEIR data instead of the built-in demo'. It also provides an alternative: 'Call reset_intraday_data to restore the demo dataset', giving clear when-not guidance.

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

reset_intraday_dataA

Restore the built-in demo Intraday dataset (undo load_intraday_data).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the action of restoring demo data but does not mention potential destructive side effects (e.g., overwriting custom data) or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, efficient, front-loaded with key action. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless tool with no output schema and no annotations, the description provides sufficient context (purpose and relation to sibling). Could mention what happens to existing data, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the description adds value by explaining the tool's effect beyond the empty schema. Baseline for zero parameters is 4, and the description meets it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it restores the built-in demo Intraday dataset and explicitly positions itself as the undo operation for load_intraday_data, distinguishing it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage as a revert action after load_intraday_data, providing clear context. However, it does not explicitly state when not to use or mention alternative approaches.

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

resolve_intraday_entityB

Resolve a user-friendly name (e.g. 'billing', 'GE') to a canonical queue.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility. It does not mention any behavioral traits such as side effects, permissions needed, error handling, or what happens if the name cannot be resolved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words. It front-loads the action and includes helpful examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers the basic purpose. However, it lacks details on possible name formats, error cases, or what a 'canonical queue' represents, leaving some ambiguity for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 0%, the description adds significant meaning to the 'name' parameter by explaining it is a 'user-friendly name' and the tool resolves it to a 'canonical queue'. This clarifies the parameter's purpose beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'resolve' and the resource: converting a 'user-friendly name' to a 'canonical queue'. The examples ('billing', 'GE') aid understanding. However, it does not differentiate from sibling tools, though siblings appear to serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. Sibling tools are listed but no context is given about their use cases or when to prefer one over another.

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

simulate_recovery_actionB

Simulate moving N agents from a source queue to a target queue for a duration (minutes).

ParametersJSON Schema

Name	Required	Description	Default
`agents`	Yes
`source`	Yes
`target`	Yes
`minutes`	No

TDQS

B3.3/5.0

Behavior2/5

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

Given no annotations, the description must fully disclose behavioral traits. It states 'simulate' implying no actual state change, but it does not explicitly confirm read-only behavior, mention any side effects, or describe the output format. Lack of annotation makes this a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence of 13 words that immediately conveys the core action. Every word serves a purpose with no redundancy or extraneous detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides the essential idea for a straightforward simulation tool. However, it omits what the simulation returns (e.g., predicted metrics) and any conditions under which the simulation is valid. Given the lack of output schema, this information is necessary for complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaning by mapping 'N agents' to the agents parameter, 'source queue' and 'target queue' to source and target, and 'duration (minutes)' to minutes. However, it does not specify valid values or constraints such as queue name format or integer ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool simulates moving a number of agents from one queue to another for a specified duration. This verb+resource combination is distinct from sibling tools which focus on capacity, forecasts, and intraday metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No instructions are provided on when to use this tool versus alternatives such as get_available_capacity or get_intraday_snapshot. The description does not specify prerequisites or typical use cases.

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

summarise_intraday_recommendationC

Return a plain-English recovery recommendation (what / why / action / impact / trade-offs).

ParametersJSON Schema

Name	Required	Description	Default
`target_queue`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided; description carries full burden. It does not disclose whether the tool is read-only, modifies state, or requires authentication. The mention of 'recovery recommendation' implies computation but side effects are unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff, front-loaded with key info. Could be slightly expanded to include parameter hints without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description lists output components partially compensating for missing output schema. However, no parameter info and limited behavioral context leave gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'target_queue' is not described in either the schema or the tool description. With 0% schema description coverage, the agent has no guidance on what value to provide or its format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly specifies verb 'Return' and resource 'plain-English recovery recommendation' with components (what/why/action/impact/trade-offs). Does not explicitly distinguish from sibling tools like 'simulate_recovery_action', but purpose is sufficiently clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., after simulation or for reporting). No context about prerequisites or expected input state.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv0.1.0Jul 16, 2026
- First observedget_available_capacity
- First observedget_forecast_vs_actual
- First observedget_intraday_risk_drivers
- First observedget_intraday_snapshot
- First observedlist_intraday_metrics
- First observedload_intraday_data
- First observedreset_intraday_data
- First observedresolve_intraday_entity
- First observedsimulate_recovery_action
- First observedsummarise_intraday_recommendation

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-16 11:05 across 10 tools

Disambiguation5/5

Each tool has a distinct purpose: snapshot, forecast comparison, risk analysis, capacity query, simulation, recommendation, data loading/reset, entity resolution, metrics listing. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_available_capacity, simulate_recovery_action, reset_intraday_data). No mixing of conventions.

Tool Count5/5

10 tools is well-scoped for a WFM intraday server. Each tool serves a needed function without being excessive or too sparse.

Completeness4/5

Covers snapshot, forecast comparison, risk analysis, capacity, simulation, recommendation, and data management. Minor gap: no direct tool for updating individual queue attributes, but load_intraday_data allows bulk replacement.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
Unified.to MCP Server C
to.unified.docs
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
App Automation Agent Orchestration Developer Tools
252
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
CData Connect AIOAuth
com.cdata
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
Databases RAG Systems Cloud Platforms
2

Related MCP Servers

ToolBridge
CRM Customer Support
AlexlaGuardia
F
license
Not graded
quality
D
maintenance
A governed MCP server for integrating AI agents with customer data, featuring role-based access control, field redaction, and human-in-the-loop approval for secure support operations.
Updated 3 months ago (2026-06-12 16:41 UTC)
1
-
Deputy Workforce Operations
ERP Systems Workplace & Productivity
hyperdrift-io
A
license
A
quality
B
maintenance
A read-only MCP server that transforms Deputy workforce records into operational workflows, enabling AI assistants to answer questions about coverage gaps, overtime risk, timesheet exceptions, availability conflicts, and staffing summaries.
Updated 2 months ago (2026-07-27 22:06 UTC)
5
20 npm
MIT
NetPulse
hind77
A
license
A
quality
D
maintenance
An MCP server that exposes live network monitoring data as Resources and diagnostic capabilities as Tools, letting AI assistants query network health conversationally.
Updated 6 months ago (2026-03-18 23:55 UTC)
6
MIT
five9-mcp
Customer Support CRM
five9-tam
A
license
Not graded
quality
C
maintenance
MCP server connecting AI assistants to the Five9 contact center, enabling management of campaigns, agents, IVR flows, and reports via natural language.
Updated 2 months ago (2026-08-04 06:30 UTC)
MIT