Skip to main content
Glama
Sign In
Date Math – Business Days, Holidays & Time Zones

Date Math – Business Days, Holidays & Time Zones

by JowenDelaPena
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Normalize timestamps

timestamp_normalize
Read-onlyIdempotent

Detect and convert mixed timestamps—Unix, Excel, FILETIME, ISO, RFC—to UTC ISO 8601 while flagging ambiguous values so you can clean CSV, log, and spreadsheet data.

Instructions

Detect and convert up to 100 mixed timestamps to UTC ISO 8601: Unix seconds/ms/µs/ns, Excel serial dates, Windows FILETIME, ISO 8601, RFC 2822, YYYY/MM/DD, month-name dates. Flags ambiguous values (03/04/2026: March 4 or 3 April? 45000: Excel date or Unix seconds?) with alternatives. Use for cleaning CSV, log and spreadsheet data. 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": {
      "values": "<values>"
    },
    "name": "timestamp_normalize"
  }
}

Input Schema

NameRequiredDescriptionDefault
valuesYesTimestamps as strings or numbers. Pass very large integers (ns) as strings.
timezoneNoZone for values without an offset and for the local output (default UTC)
date_orderNoHow to read ambiguous slash dates like 03/04/2026 (default MDY, with the other reading in alternatives)
numeric_formatNoauto

Output Schema

NameRequiredDescriptionDefault
okYesHow many values were understood
countYes
resultsYes
timezoneYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds behavior that structured fields cannot: ambiguity is flagged with alternative readings rather than silently guessed, with worked examples ('03/04/2026: March 4 or 3 April?'). It also discloses pricing and quota (first 25 calls/day free, then $0.001 per call via x402), which is material to whether an agent should batch calls.

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 format list is front-loaded and dense, and every sentence carries information (capabilities, ambiguity handling, use case, pricing). It is a single packed block with no headers or line breaks, which makes the cost note easy to skim past, but there is no filler text.

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?

With an output schema present, return structure needn't be described, and the description covers capability scope, ambiguity policy, batch limit, and cost. The main residual gap is error handling for unconvertible values, which is presumably in the output schema but not signposted; otherwise the definition is sufficient to call the tool correctly.

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?

Schema coverage is 75%, so the schema carries most of the load, but the description still adds meaning: it explains why date_order matters (disambiguating 03/04/2026) and illustrates the numeric ambiguity (45000 as Excel date vs Unix seconds) that the auto-detection in numeric_format resolves. The 100-item cap is echoed from maxItems but tied to the batching behavior rather than restated blindly.

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 opens with a specific verb and resource ('Detect and convert up to 100 mixed timestamps to UTC ISO 8601') and enumerates exactly which formats are handled (Unix s/ms/µs/ns, Excel serial, FILETIME, ISO 8601, RFC 2822, YYYY/MM/DD, month-name). It is unambiguous what the tool does. It does not, however, differentiate itself from the sibling parse_date_text or timezone_convert, so an agent must infer the boundary from the batch/normalize framing.

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?

'Use for cleaning CSV, log and spreadsheet data' gives a concrete usage context that implies batch, messy-data input. There is no explicit when-not guidance and no sibling is named as an alternative (e.g. parse_date_text for single free-text dates), so routing still requires inference, but the positive guidance is clear.

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

Deploy Server

Other Tools