FiatDock

Time zone conversion (IANA tz database, DST-aware) ($0.001)

timezone_convert

Read-onlyIdempotent

PAID ($0.001 USDC via x402). Shows one instant in up to 20 IANA time zones (localTime with offset, utcOffset, abbreviation, isDst, dayOfWeek, date). time with Z/offset is absolute; without, it is wall-clock in from (default UTC). A skipped local time moves forward by the gap, a repeated one takes the earlier instant (localTimeIssue + alternativeInstantUtc). Rules come from the tz database built into the server; future dates use today's published rules. An unknown zone answers 404, bad input 400; neither is charged. Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically. Any answer the tool cannot produce is >= 400 and is NOT charged.

Input Schema

Name	Required	Description
`to`	No	IANA time zones to show the instant in, up to 20 (default America/Los_Angeles,America/New_York,Europe/London,Europe/Berlin,Asia/Dubai,Asia/Kolkata,Asia/Tokyo,Australia/Sydney)
`from`	No	IANA time zone a local `time` is read in (and shown in as fromLocalTime), e.g. America/New_York; default UTC
`time`	No	The moment to convert, ISO 8601: with Z or an offset ("2026-10-08T15:00:00Z", "2026-10-08T15:00+02:00") it is an absolute instant; without one ("2026-10-08T15:00") it is wall-clock time in `from`; a bare date means 00:00 there. Years 1970-2100. Default: now
`payment`	No	Base64 of a single x402 v2 PaymentPayload (EIP-3009 transferWithAuthorization on Base USDC). OMIT it on the first call: the 402 you get back carries `howToPay.payloadTemplate` — the exact envelope to fill in — plus the price and the EIP-712 domain. Send it on the second call to complete the purchase; it is forwarded as the PAYMENT-SIGNATURE header, never as body data. Nothing is charged for the 402 itself, and a call that fails after payment settles nothing.

Output Schema

Name	Required	Description
`asOf`	Yes	ISO time the conversion was computed
`from`	Yes	The zone a local `time` was read in (default UTC)
`note`	Yes	How a local time, DST and the abbreviation are decided, and the limits
`count`	Yes	Zones returned
`times`	Yes	The instant in each requested zone, in the order asked
`source`	Yes	Where the time zone rules came from (the tz database version compiled into this server)
`instantUtc`	Yes	The instant converted, in UTC (ISO 8601)
`fromLocalTime`	Yes	The instant as wall-clock time in `from`, ISO 8601 with offset
`inputWasLocal`	Yes	True when `time` had no Z or offset and was read as wall-clock time in `from`
`localTimeIssue`	Yes	For a local `time` only: "nonexistent" = that wall-clock time does not happen in `from` (clocks went forward) and was moved forward by the gap; "ambiguous" = it happens twice (clocks went back) and the EARLIER instant was taken. null otherwise
`alternativeInstantUtc`	Yes	For an ambiguous local `time`: the LATER of its two instants, in UTC. null otherwise

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses the payment cost, the 402 challenge flow, that errors (404 unknown zone, 400 bad input) are not charged, DST edge-case behavior (skipped/repeated local times with localTimeIssue and alternativeInstantUtc), and that the tz database is built into the server with future dates using today's rules. This is rich behavioral context with no contradiction to the annotations.

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 dense but front-loaded with the key PAID constraint and purpose. Every sentence carries useful information, though the single-paragraph structure and some repetition of schema details prevent a perfect score for conciseness.

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 the complexity of a paid x402 tool with DST edge cases and an output schema, the description covers everything an agent needs: payment flow, error charge policy, input interpretation, and edge-case behavior. Return values are covered by the output schema and briefly previewed in the description.

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 description coverage is 100%, establishing a baseline of 3. The description adds meaning beyond the schema by explaining DST gap/overlap handling for `time` and by detailing the two-step payment flow for `payment` (omit first call, send on second), which is not fully captured in the parameter's schema description.

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 states a specific verb and resource: it shows one instant in up to 20 IANA time zones and enumerates the returned fields (localTime with offset, utcOffset, abbreviation, isDst, dayOfWeek, date). This clearly distinguishes it from all sibling tools, none of which perform time-zone conversion.

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?

The description provides clear operational context: it is paid, how to handle the initial 402 challenge, how to send payment, and how to interpret the `time` parameter with or without offsets. It does not name alternatives or explicit exclusions, but the tool is unique among siblings so no alternative routing is needed.

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

All FiatDock tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.