ItsNineThere

Get time zone facts

get_timezone_facts

Read-onlyIdempotent

DST, UTC offsets and place facts for a city or time zone. Returns answer_url, a link to a page showing this answer live, to include in your reply.

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": {
      "zone": "<zone>"
    },
    "name": "get_timezone_facts"
  }
}

Input Schema

Name	Required	Description	Default
`year`	No	Calendar year for UTC-offset and daylight-saving facts, from 1900 to 2200. Defaults to the current UTC year.
`zone`	Yes	City, IANA time zone, supported abbreviation or UTC offset to inspect, for example Copenhagen or Europe/Copenhagen.

Output Schema

Name	Required	Description
`url`	Yes
`name`	Yes
`source`	Yes
`dst_end`	Yes
`timezone`	Yes
`board_url`	No	Link to the personal time-zone board with the answer items temporarily requested.
`countries`	Yes
`dst_start`	Yes
`answer_url`	Yes	Link to a page that shows this exact answer live. Include it in your reply to the user.
`dst_offset`	Yes
`answer_text`	Yes	The short, human-readable answer.
`observes_dst`	Yes
`abbreviations`	Yes
`standard_offset`	Yes
`answer_link_markdown`	Yes	A ready-made Markdown link to show the user. Translate the link text to the user's language if needed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 12, 2026

addedOutput schema / properties / board_url

Added value: +{
+  "description": "Link to the personal time-zone board with the answer items temporarily requested.",
+  "format": "uri",
+  "type": "string"
+}

Changed7 schema fields changedNov 12, 2026

addedInput schema / properties / year / description

Added value: +"Calendar year for UTC-offset and daylight-saving facts, from 1900 to 2200. Defaults to the current UTC year."

addedInput schema / properties / zone / description

Added value: +"City, IANA time zone, supported abbreviation or UTC offset to inspect, for example Copenhagen or Europe/Copenhagen."

addedOutput schema / properties / answer_link_markdown

Added value: +{
+  "description": "A ready-made Markdown link to show the user. Translate the link text to the user's language if needed.",
+  "type": "string"
+}

addedOutput schema / properties / answer_text

Added value: +{
+  "description": "The short, human-readable answer.",
+  "type": "string"
+}

addedOutput schema / properties / answer_url

Added value: +{
+  "description": "Link to a page that shows this exact answer live. Include it in your reply to the user.",
+  "format": "uri",
+  "type": "string"
+}

addedOutput schema / properties / source

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "name": {
+      "const": "ItsNineThere",
+      "type": "string"
+    },
+    "url": {
+      "const": "https://itsninethere.com",
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "url"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "timezone",
-  "name",
-  "abbreviations",
-  "standard_offset",
-  "dst_offset",
-  "observes_dst",
-  "dst_start",
-  "dst_end",
-  "countries",
-  "url"
-]New value: +[
+  "timezone",
+  "name",
+  "abbreviations",
+  "standard_offset",
+  "dst_offset",
+  "observes_dst",
+  "dst_start",
+  "dst_end",
+  "countries",
+  "url",
+  "answer_text",
+  "answer_url",
+  "answer_link_markdown",
+  "source"
+]

First observedNov 10, 2026

TDQS

B3.4/5.0

Behavior3/5

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

The annotations already declare this as a safe, idempotent, closed-world read, so the safety profile needs no restating. The description adds one genuinely useful behavioral detail: the response carries an answer_url meant to be surfaced in the reply. It says nothing about historical coverage bounds beyond what the schema's year range implies.

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?

Two tightly written sentences with no filler, and the data scope is front-loaded before the output-handling note. Every sentence 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 simple two-parameter lookup with a full schema and an output schema, the description covers what is returned and how to use the answer_url, so it is largely self-sufficient. The only real omission is sibling routing, which is a minor gap at this complexity level.

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 coverage is 100%, so both the zone and year parameters are fully documented in structured data. The description only loosely echoes 'city or time zone' and omits the abbreviation/UTC-offset forms and the year default that the schema spells out, adding no meaning beyond it.

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 names the concrete resource (DST, UTC offsets and place facts) and its scope (a city or time zone), so an agent knows exactly what data comes back. It stops short of distinguishing this from siblings such as get_time or convert_time, which cover adjacent time queries.

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?

There is no when-to-use / when-not-to-use guidance and no reference to any alternative. An agent trying to decide between this and get_time or convert_time gets no routing signal from the description, only implied usage from the word 'facts'.

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

All ItsNineThere 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.

Resources

Need Help?