Date Math

SLA countdown (business hours)

sla_countdown

Read-onlyIdempotent

Live SLA clock for a support ticket: business minutes elapsed and remaining, breached or not, and the deadline. The clock pauses outside working hours, on weekends and holidays, and during manual pauses (e.g. waiting on customer). Custom hours, workdays, country holidays, DST-aware. Use for support-agent SLA tracking and escalation. First 25 calls per day are free, then $0.001 per call (x402).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start": "<start>",
      "timezone": "<timezone>"
    },
    "name": "sla_countdown"
  }
}

Input Schema

Name	Required	Description
`now`	No	Current time (default: now), same formats as start
`start`	Yes	When the SLA clock started: ISO 8601 with offset, or local YYYY-MM-DDTHH:MM in timezone
`pauses`	No	Manual pauses (e.g. waiting on customer), up to 100
`country`	No	ISO 3166-1 alpha-2 country code (207 countries); its public holidays (2000–2050) are excluded from business days
`holidays`	No	Extra dates excluded from business-day counts (rest days from workdays are always excluded)
`timezone`	Yes	IANA time zone of the support team's working hours
`work_end`	No	End of working hours, default 17:00
`workdays`	No	Working days of the week, 0 = Sunday. Default [1,2,3,4,5] (Mon–Fri); e.g. [0,1,2,3,4] for Sun–Thu or [1,2,3,4,5,6] for Mon–Sat
`sla_hours`	No	SLA target in business hours (combine with sla_minutes)
`work_start`	No	Start of working hours, default 09:00
`sla_minutes`	No	SLA target in business minutes

Output Schema

Name	Required	Description
`now`	Yes
`start`	Yes
`status`	Yes
`breached`	Yes
`deadline`	Yes
`timezone`	Yes
`resumes_at`	Yes	When the clock restarts, if paused by working hours
`sla_minutes`	Yes
`deadline_utc`	Yes
`percent_used`	Yes
`deadline_weekday`	Yes
`elapsed_business_minutes`	Yes
`remaining_business_minutes`	Yes
`breached_by_business_minutes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations only say readOnly/idempotent/closed-world; the description adds substantial behavior beyond that: the clock pauses outside working hours, on weekends, holidays and manual pauses, is DST-aware, and is configurable to custom hours/workdays/country holidays. It also discloses cost and rate limits (first 25 calls/day free, then $0.001 per call via x402), which no structured field carries.

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?

Front-loaded with the core definition and return values in the first sentence; supporting sentences cover pausing, configurability and pricing in a logical order with no filler. The mid-sentence feature list ('Custom hours, workdays, country holidays, DST-aware') is slightly telegraphic but still 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 an 11-parameter tool with a full output schema and complete parameter documentation, the description supplies enough behavioral context (pausing logic, timezone/DST handling, billing) to call it correctly. The one meaningful gap is sibling differentiation against business_hours_deadline, which the description does not address.

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?

Schema description coverage is 100%, so every one of the 11 parameters is already documented with formats, defaults and examples. The description's mention of custom hours, workdays, country holidays and manual pauses merely restates the corresponding parameters without adding syntax or edge-case meaning, so the baseline 3 applies.

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?

Opens with a specific verb+resource: 'Live SLA clock for a support ticket' and enumerates exactly what is returned (elapsed/remaining business minutes, breach status, deadline). The purpose is unmistakable, but the description never distinguishes it from the very similar sibling business_hours_deadline, so an agent cannot route between them from this text alone.

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

Usage Guidelines3/5

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

'Use for support-agent SLA tracking and escalation' gives a clear usage context, which meets the 'clear context' bar. However, it offers no exclusions and no named alternatives, despite two close siblings (business_hours_deadline, business_day) existing — an agent has no guidance on when this tool is the wrong choice.

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

All Date Math tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.