bug(openaq_get_measurements): normalize mixed date and datetime ranges

[cyanheads]

Server version

0.1.3

mcp-ts-core version

0.10.10

Runtime

Bun

Runtime version

Bun 1.3.11

Transport

HTTP (Streamable HTTP)

OS

macOS 26.1

Description

openaq_get_measurements accepts both date-only (YYYY-MM-DD) and UTC date-time (YYYY-MM-DDTHH:MM:SSZ) inputs, but validates ordering with a raw string comparison. Mixed formats can be misclassified locally or forwarded to OpenAQ in a shape that returns a retried HTTP 500.

Steps to reproduce

1. Start the server with OPENAQ_API_KEY set and call openaq_get_measurements over HTTP.
2. Call with same-day mixed formats:

{"locationId":931,"parametersId":2,"aggregation":"daily","datetimeFrom":"2026-06-25T00:00:00Z","datetimeTo":"2026-06-25","limit":1000}

3. Call the reverse mixed format:

{"locationId":931,"parametersId":2,"aggregation":"daily","datetimeFrom":"2026-06-25","datetimeTo":"2026-06-25T00:00:00Z","limit":1000}

Actual behavior

First call is rejected before hitting OpenAQ:

Error: datetimeTo is before datetimeFrom.

Recovery: Ensure datetimeTo is on or after datetimeFrom.

Second call passes local validation but OpenAQ returns a retried 500:

Error: OpenAQ returned HTTP 500. (failed after 3 attempts)
path: /sensors/1701/measurements/daily?datetime_from=2026-06-25&datetime_to=2026-06-25T00%3A00%3A00Z&limit=1000&page=1

Expected behavior

The tool should normalize both accepted input forms before comparing and before forwarding upstream, or constrain the schema to one date format. Valid same-day ranges should not be rejected, and malformed/mixed upstream-incompatible ranges should fail locally with invalid_date_range instead of producing a transient upstream 500.

Additional context

A full date-time range works:

{"locationId":931,"parametersId":2,"aggregation":"daily","datetimeFrom":"2026-06-25T00:00:00Z","datetimeTo":"2026-06-26T00:00:00Z","limit":1000}