Skip to main content
Glama
Sign In

mcp-time

by io.github.mcpcentral-io
OverviewDiscussionsAdmin

Server Details

Time MCP server via HTTP

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
28.5% over 81 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
mcpcentral-io/mcp-time
GitHub Stars
3
Server Listing
MCP Time Server
ChatGPT
–
Claude
–

TDQS

A3.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct time operation: timezone conversion, current time retrieval, month length, Unix timestamp conversion, ISO week number, and relative time from now. There is no meaningful overlap in purpose, so an agent can select unambiguously. The only faint adjacency is convert_time vs relative_time, but their inputs and outputs are clearly different.

Naming Consistency4/5

All names are snake_case and readable, sharing the *_time/time-worded family, but the verb style is inconsistent: some use an explicit verb (convert_time, get_timestamp, get_week_year) while others are noun-like (current_time, days_in_month, relative_time). This is a minor deviation rather than a real inconsistency.

Tool Count5/5

Six tools is a tight, well-scoped surface for a time utility server, with each tool covering a genuinely different capability. Nothing feels padded or missing at the count level.

Completeness3/5

The surface covers timezone conversion, current time, calendar facts, and timestamp/relative conversion, but has notable gaps: no reverse conversion (Unix timestamp back to a date string), no time arithmetic (add/subtract durations or diff two arbitrary dates), and no timezone listing. An agent needing those operations would hit dead ends.

Available Tools

6 tools
convert_timeConvert TimezoneBInspect

Converts a time from a source timezone to a target timezone.

NameRequiredDescriptionDefault
timeYesThe time to convert. e.g., "2025-03-23 12:30:00".
sourceTimezoneYesThe source IANA timezone name (e.g., "Asia/Shanghai").
targetTimezoneYesThe target IANA timezone name (e.g., "Europe/London").

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing beyond the core action. It says nothing about DST handling, whether the conversion is purely computational, what format the result takes, or how invalid timezone names are handled.

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?

A single sentence with zero filler, front-loading both the action and the two timezone roles. Nothing is padded or repeated from the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter deterministic utility with full schema coverage, the description is adequate but skips the one gap the schema cannot fill: there is no output schema, so the description should say what the converted result looks like. It also omits any DST or edge-case behavior.

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 all three parameters (time, sourceTimezone, targetTimezone) are already documented with examples in the schema itself. The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 states a specific verb (converts) and resource (a time) plus the operative dimensions (source timezone to target timezone), so the purpose is unambiguous. It does not explicitly contrast itself with siblings like current_time or relative_time, but the name and description make the distinction obvious anyway.

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 guidance on when to use this tool versus the many sibling time tools, no mention of prerequisites, and no exclusions. An agent must infer that this is the right pick whenever an explicit timezone-to-timezone conversion is needed, with nothing to confirm that inference.

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

current_timeGet Current TimeBInspect

Returns the current time in UTC and a specified or guessed timezone.

NameRequiredDescriptionDefault
formatNoThe format for the returned time string. Either a dayjs token string (e.g. "YYYY-MM-DD HH:mm:ss") or a named format: "iso8601" / "rfc3339" (ISO 8601 UTC), "unix" (epoch seconds), "unix_ms" (epoch milliseconds).YYYY-MM-DD HH:mm:ss
timezoneNoThe IANA timezone name (e.g., "America/New_York"). Defaults to the server's guessed timezone.

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose one real behavioral trait — that the timezone falls back to a server-side guess when unspecified — but says nothing about invalid timezone handling, error behavior, or output characteristics.

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?

A single front-loaded sentence with no filler. Slightly loose phrasing ('in UTC and a specified or guessed timezone') introduces a small ambiguity about what the returned string actually contains.

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?

This is a zero-required-parameter read tool with a fully documented schema and no output schema, so the description is nearly sufficient as-is. Only the missing differentiation from sibling time tools is a notable gap.

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 both parameters (format, timezone) are already fully documented with named formats and IANA examples. The description's mention of 'specified or guessed timezone' adds marginal context but no syntax or format detail beyond the schema.

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 states a specific verb (Returns) and resource (the current time) with the output basis (UTC plus a specified or guessed timezone), which is clear enough to act on. It does not differentiate itself from siblings like get_timestamp or relative_time, which is the only thing keeping it from a 5.

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 guidance on when to use this tool versus the five siblings (convert_time, get_timestamp, relative_time, etc.), and no mention of exclusions or prerequisites. Usage is only inferable from the purpose statement.

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

days_in_monthGet Days in MonthBInspect

Returns the number of days in the month of a given date.

NameRequiredDescriptionDefault
dateNoThe date to check. Format: YYYY-MM-DD

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, but this is a pure computation with no side effects, and the description states what it returns. It does not mention leap-year handling, which is the one non-obvious behavioral edge for this operation.

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?

A single front-loaded sentence with no filler; every word 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 one-parameter pure function with no output schema and full schema coverage, the description is essentially complete. Only leap-year semantics are left unstated.

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 the date parameter's format (YYYY-MM-DD) is already documented. The description adds only that the month component of the date is what matters, which is marginal value.

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?

States a specific verb and resource: 'Returns the number of days in the month of a given date.' An agent can tell this apart from siblings like get_week_year or current_time, though it doesn't explicitly name the distinction.

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?

No guidance on when to use this versus the sibling time utilities (e.g., get_week_year, get_timestamp). For a simple utility the need is mild, but nothing is stated.

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

get_timestampGet TimestampBInspect

Converts a date-time string to a Unix timestamp in milliseconds.

NameRequiredDescriptionDefault
timeNoThe time to convert. Format: YYYY-MM-DD HH:mm:ss

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the output unit (milliseconds), but a timestamp conversion hinge on timezone handling (UTC vs local) and behavior on null/unparsable input, neither of which is stated — a real gap for the only parameter, which has no default despite being non-required.

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?

One front-loaded sentence with zero waste. It is efficient, though the brevity leaves too much unsaid rather than being over-optimized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter pure-conversion tool with a fully described schema, this is close to adequate. The absence of timezone semantics and default-input behavior leaves a meaningful gap an agent would want resolved before invoking.

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% and the single parameter is fully documented with its format in the schema, so the baseline is 3. The description adds nothing beyond restating the input type, and does not clarify what a missing non-required 'time' value does.

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?

States a specific verb and transformation ('Converts a date-time string to a Unix timestamp in milliseconds'), so the input and output types are unambiguous. However, it does not differentiate itself from the sibling 'convert_time', which plausibly does the same conversion, leaving the agent to guess which one to pick.

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?

No guidance on when to use this rather than 'convert_time', 'relative_time', or 'current_time'. The description gives no context, prerequisites, or exclusions at all.

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

get_week_yearGet Week of YearBInspect

Returns the week and ISO week number for a given date.

NameRequiredDescriptionDefault
dateNoThe date to check. e.g., "2025-03-23"

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does signal a pure read/compute operation returning two values. However, it never resolves the ambiguity between 'the week' and 'the ISO week number' (are these two different numbering schemes?), nor does it mention boundary behavior at year edges where ISO weeks diverge from locale weeks. Modest disclosure for a low-risk tool, but the key semantic ambiguity is left open.

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?

A single front-loaded sentence with no filler; the resource and return values come first and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and the description covers the core behavior, but the context signals show 0 required parameters, meaning 'date' is optional, and the description says 'for a given date' without stating what happens when it is omitted (today? error?). That is a real operational gap for a parameter the description implies is needed.

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% and the schema already documents the date parameter with a concrete format example ('2025-03-23'), so the description adds nothing beyond it. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ('Returns the week and ISO week number for a given date'), so an agent can tell it computes a calendar-derived value rather than returning the current time like current_time or a raw epoch like get_timestamp. It does not explicitly name or contrast with any sibling, so it falls short of 5.

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 guidance, no mention of when to prefer this over current_time, relative_time, or convert_time, and no prerequisites stated. The agent must infer the use case entirely from the name.

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

relative_timeGet Relative TimeBInspect

Calculates the relative time from now to a given time string.

NameRequiredDescriptionDefault
timeYesThe time to compare. Format: YYYY-MM-DD HH:mm:ss

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. 'Calculates... from now' usefully signals a read-only, pure computation anchored to the current moment. However, it does not disclose the return format (e.g., '3 days ago' vs. a seconds count) or timezone assumptions for parsing the input string, which matter for a time tool with no output schema.

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?

One efficient sentence with the core operation front-loaded and no filler. It is quite terse, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter tool this covers the input well, but with no output schema and no annotations the description should say what value comes back (human-readable string? duration?) and how the input timestamp's timezone is interpreted. Those omissions leave meaningful ambiguity for an agent.

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?

The single parameter has 100% schema description coverage including the exact format string, so the schema already does the heavy lifting. The description adds only that the time is compared against 'now', which is modest added value.

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?

States a specific verb ('Calculates') and resource ('relative time from now to a given time string'), which is enough to distinguish it from siblings like current_time and convert_time. It does not explicitly name those siblings, but the operation is unambiguous.

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 guidance on when to use this tool versus convert_time or get_timestamp, and no mention of when not to use it. The agent must infer the use case from the verb alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updates
    • Changedconvert_time7 fields changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / sourceTimezone / description
        Previous value: -"Source IANA timezone name (e.g., \"Asia/Shanghai\")"New value: +"The source IANA timezone name (e.g., \"Asia/Shanghai\")."
      • changedInput schema / properties / targetTimezone / description
        Previous value: -"Target IANA timezone name (e.g., \"Europe/London\")"New value: +"The target IANA timezone name (e.g., \"Europe/London\")."
      • changedInput schema / properties / time / description
        Previous value: -"The time to convert (e.g., \"2025-03-23 12:30:00\")"New value: +"The time to convert. e.g., \"2025-03-23 12:30:00\"."
      • changedInput schema / required
        Previous value: -[
-  "time",
-  "sourceTimezone",
-  "targetTimezone"
-]New value: +[
+  "sourceTimezone",
+  "targetTimezone",
+  "time"
+]
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "convertedTime": {
-      "type": "string"
-    },
-    "hourDifference": {
-      "type": "number"
-    }
-  },
-  "required": [
-    "convertedTime",
-    "hourDifference"
-  ],
-  "type": "object"
-}New value: +null
    • Changedcurrent_time6 fields changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / format / default
        Added value: +"YYYY-MM-DD HH:mm:ss"
      • changedInput schema / properties / format / description
        Previous value: -"Format for the returned time string (default YYYY-MM-DD HH:mm:ss)"New value: +"The format for the returned time string. Either a dayjs token string (e.g. \"YYYY-MM-DD HH:mm:ss\") or a named format: \"iso8601\" / \"rfc3339\" (ISO 8601 UTC), \"unix\" (epoch seconds), \"unix_ms\" (epoch milliseconds)."
      • changedInput schema / properties / timezone / description
        Previous value: -"IANA timezone name (e.g., \"America/New_York\"). Defaults to the server's guessed timezone"New value: +"The IANA timezone name (e.g., \"America/New_York\"). Defaults to the server's guessed timezone."
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "localTime": {
-      "type": "string"
-    },
-    "timezone": {
-      "type": "string"
-    },
-    "utcTime": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "utcTime",
-    "localTime",
-    "timezone"
-  ],
-  "type": "object"
-}New value: +null
    • Changeddays_in_month4 fields changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / date / description
        Previous value: -"The date to check (format: YYYY-MM-DD). Defaults to current date"New value: +"The date to check. Format: YYYY-MM-DD"
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "days": {
-      "type": "integer"
-    }
-  },
-  "required": [
-    "days"
-  ],
-  "type": "object"
-}New value: +null
    • Changedget_timestamp4 fields changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / time / description
        Previous value: -"The time to convert (format: YYYY-MM-DD HH:mm:ss). Defaults to current time"New value: +"The time to convert. Format: YYYY-MM-DD HH:mm:ss"
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "timestamp": {
-      "type": "number"
-    }
-  },
-  "required": [
-    "timestamp"
-  ],
-  "type": "object"
-}New value: +null
    • Changedget_week_year4 fields changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / date / description
        Previous value: -"The date to check (e.g., \"2025-03-23\"). Defaults to current date"New value: +"The date to check. e.g., \"2025-03-23\""
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "isoWeek": {
-      "type": "integer"
-    },
-    "week": {
-      "type": "integer"
-    }
-  },
-  "required": [
-    "week",
-    "isoWeek"
-  ],
-  "type": "object"
-}New value: +null
    • Changedrelative_time4 fields changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / time / description
        Previous value: -"The time to compare (format: YYYY-MM-DD HH:mm:ss)"New value: +"The time to compare. Format: YYYY-MM-DD HH:mm:ss"
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "relativeTime": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "relativeTime"
-  ],
-  "type": "object"
-}New value: +null
  2. 6 tool updates
    • Changedconvert_time7 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / sourceTimezone / description
        Previous value: -"The source IANA timezone name (e.g., \"Asia/Shanghai\")."New value: +"Source IANA timezone name (e.g., \"Asia/Shanghai\")"
      • changedInput schema / properties / targetTimezone / description
        Previous value: -"The target IANA timezone name (e.g., \"Europe/London\")."New value: +"Target IANA timezone name (e.g., \"Europe/London\")"
      • changedInput schema / properties / time / description
        Previous value: -"The time to convert. e.g., \"2025-03-23 12:30:00\"."New value: +"The time to convert (e.g., \"2025-03-23 12:30:00\")"
      • changedInput schema / required
        Previous value: -[
-  "sourceTimezone",
-  "targetTimezone",
-  "time"
-]New value: +[
+  "time",
+  "sourceTimezone",
+  "targetTimezone"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "convertedTime": {
+      "type": "string"
+    },
+    "hourDifference": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "convertedTime",
+    "hourDifference"
+  ],
+  "type": "object"
+}
    • Changedcurrent_time6 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / format / default
        Removed value: -"YYYY-MM-DD HH:mm:ss"
      • changedInput schema / properties / format / description
        Previous value: -"The format for the returned time string."New value: +"Format for the returned time string (default YYYY-MM-DD HH:mm:ss)"
      • changedInput schema / properties / timezone / description
        Previous value: -"The IANA timezone name (e.g., \"America/New_York\"). Defaults to the server's guessed timezone."New value: +"IANA timezone name (e.g., \"America/New_York\"). Defaults to the server's guessed timezone"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "localTime": {
+      "type": "string"
+    },
+    "timezone": {
+      "type": "string"
+    },
+    "utcTime": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "utcTime",
+    "localTime",
+    "timezone"
+  ],
+  "type": "object"
+}
    • Changeddays_in_month4 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / date / description
        Previous value: -"The date to check. Format: YYYY-MM-DD"New value: +"The date to check (format: YYYY-MM-DD). Defaults to current date"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "days": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "days"
+  ],
+  "type": "object"
+}
    • Changedget_timestamp4 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / time / description
        Previous value: -"The time to convert. Format: YYYY-MM-DD HH:mm:ss"New value: +"The time to convert (format: YYYY-MM-DD HH:mm:ss). Defaults to current time"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "timestamp": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "timestamp"
+  ],
+  "type": "object"
+}
    • Changedget_week_year4 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / date / description
        Previous value: -"The date to check. e.g., \"2025-03-23\""New value: +"The date to check (e.g., \"2025-03-23\"). Defaults to current date"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "isoWeek": {
+      "type": "integer"
+    },
+    "week": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "week",
+    "isoWeek"
+  ],
+  "type": "object"
+}
    • Changedrelative_time4 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / time / description
        Previous value: -"The time to compare. Format: YYYY-MM-DD HH:mm:ss"New value: +"The time to compare (format: YYYY-MM-DD HH:mm:ss)"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "relativeTime": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "relativeTime"
+  ],
+  "type": "object"
+}
  3. 6 tool updates
    • First observedconvert_time
    • First observedcurrent_time
    • First observeddays_in_month
    • First observedget_timestamp
    • First observedget_week_year
    • First observedrelative_time

Related MCP Connectors

Related MCP Servers

  • MCP Simple Timeserver

    andybrandt
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that allows checking local time on the client machine or current UTC time from an NTP server
    2
    33
    MIT

  • MCP Time Server

    siberianwm
    F
    license
    Not graded
    quality
    D
    maintenance
    A minimal MCP server that provides current time information with configurable timezone support set on the client side.
    -
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