What can you do with this server?

The Time Tools MCP Server provides various time manipulation functionalities, including: * Get the current date and time in YYYY-MM-DD HH:mm:ss format * Get the current date and time in ISO 8601 format * Retrieve the current Unix timestamp * Get the server's current timezone * Convert Unix timestamps to formatted datetime strings and vice versa * Calculate the difference between two datetime strings in various units (second, minute, or hour)

Which integrations are available for this server?

Used to translate prompts and content between languages, as evidenced by the example that mentions 'Translated with DeepL.com (free version)' and includes both English and Japanese versions of the same prompt. Provides image hosting for documentation screenshots, as shown by the GitHub user-attachments URLs in the image references. Used for package management and running the MCP server, with commands provided for installation (pnpm install), building (pnpm build), and running the server (pnpm start).

How do I use Time Tools MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Time Tools MCP Server what's the current time in New York?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

Time Tools MCP Server

by t-shiratori

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP server for time manipulation

A dynamic MCP server management service for time manipulation.

Related MCP server: Time MCP Server

MCP Tools

This server provides several time-related tools via the Model Context Protocol (MCP).

get_timezone

Get the current timezone of the server.

Returns:
- text : The timezone string.
  - eg Asia/Tokyo

get_unixtime

Get the current Unix timestamp (seconds since epoch).

Returns:
- text : The Unix timestamp as a string.
  - e.g. 1746627290

convert_unix_to_datetime

Convert a Unix timestamp to a formatted datetime string.

Parameters:
- unixtime ( number , required): The Unix timestamp to convert.
  - e.g. 1746627290
- timezone ( string , optional): The timezone to use (default: server's timezone).
  - eg Asia/Tokyo
- isISO ( boolean , optional): If true, returns ISO 8601 format; otherwise, returns YYYY-MM-DD HH:mm:ss .
  - eg true
Returns:
- text : The formatted datetime string.
  - eg 2025-01-01 01:01:01 or 2025-01-01T01:01:01+09:00

convert_datetime_to_unix

Convert a datetime string to a Unix timestamp (milliseconds since epoch).

Parameters:
- time ( string , required): The datetime string to convert.
  - eg 2025-01-01 01:01:01
- timezone ( string , optional): The timezone to use (default: server's timezone).
  - eg Asia/Tokyo
Returns:
- text : The Unix timestamp as a string.
  - e.g. 1746627290000

get_current_date_time

Get the current date and time in YYYY-MM-DD HH:mm:ss format.

Parameters:
- timezone ( string , optional): The timezone to use (default: server's timezone).
  - eg Asia/Tokyo
Returns:
- text : The formatted current date and time.
  - eg 2025-01-01 01:01:01

get_current_date_time_iso

Get the current date and time in ISO 8601 format.

Parameters:
- timezone ( string , optional): The timezone to use (default: server's timezone).
  - eg Asia/Tokyo
Returns:
- text : The ISO 8601 formatted current date and time.
  - eg 2025-05-07T23:03:27+09:00

get_elapsed_time

Calculate the difference between two datetime strings.

Parameters:
- from ( string , required): The start datetime.
  - eg 2025-01-01 01:01:01
- to ( string , required): The end datetime.
  - eg 2025-01-02 02:02:02
- unit ( "millisecond" | "second" | "minute" | "hour" | "day" | "week" | "month" | "year" , optional, default: "second" ): The unit for the difference.
  - e.g. "hour"
Returns:
- text : The difference between the two datetimes in the specified unit.
  - eg 3600

Prepare mcp server app

1. Install packages

pnpm install

2. Build

pnpm build

Mcp Inspector

Inspector - Model Context Protocol

pnpm inspect

get_current_date_time

get_elapsed_time

VS Code

When managed in a project

.vscode/mcp.json

{
  "servers": {
    "time-tools": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/PARENT/FOLDER/build/index.js"]
    }
  }
}

For personal global management

~/Library/Application Support/Code/User/settings.json

{
  "mcp": {
    "servers": {
      "time-tools": {
        "command": "node",
        "args": ["/ABSOLUTE/PATH/TO/PARENT/FOLDER/build/index.js"]
      }
    }
  }
}

Example prompt

## Overview
- Please perform the following tasks
- Perform the following tasks and measure the time it takes to perform the tasks.
- Please follow the time tracking requirements for the measurement method

## Tasks
- Create the src directory
- Create an empty file in it
- Name the file index.ts

## Time tracking requirements
1. retrieve and display the current time before the task starts 2.
2. retrieve and display the current time after the task is completed 3.
3. retrieve and display the elapsed time from the start and end time of the task 4. finally display the following table
4. finally display in the following table format 
|item|record| 
|:---|:---| 
|start time|<enter result>| 
|end time|<enter result>| 
|elapsed time|<enter result>|

## 概要
- 以下のタスクを実行してください
- タスク実行に要した時間も計測します
- 計測の方法はタイムトラッキング要件にしたがってください

## タスク
- src ディレクトリを作成する
- その中に空のファイルを作成する
- 作成するファイル名は index.ts とする

## タイムトラッキング要件
1. タスク開始前の現在時間を取得して表示する
2. タスク終了後の現在時間を取得して表示する
3. タスクの開始時と終了時の時間から経過時間を取得して表示する
4. 最終的に以下の表形式で表示してください
|項目|記録|
|:---|:---|
|開始時間|<結果を入力>|
|終了時間|<結果を入力>|
|経過時間|<結果を入力>|

Available Tools

7 tools

convert_datetime_to_unixC

Convert datetime time to unixtime (e.g. 2025-01-01 01:01:01 to 1746627290)

ParametersJSON Schema

Name	Required	Description	Default
`time`	Yes
`timezone`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the conversion action with an example but does not cover important traits like error handling (e.g., invalid datetime formats), timezone handling implications, or output format details. This leaves significant gaps in understanding the tool's behavior.

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?

The description is extremely concise and front-loaded, consisting of a single sentence with a clear example. Every word serves a purpose, making it efficient and easy to parse without any wasted information.

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

Completeness2/5

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

Given the tool's complexity (a conversion function with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to explain key aspects such as the return value format, error conditions, or how the 'timezone' parameter affects the conversion, leaving the agent with insufficient context for reliable use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It mentions 'datetime time' and provides an example format, which adds some meaning for the 'time' parameter. However, it does not address the 'timezone' parameter at all, leaving it undocumented. This partial coverage is insufficient for the schema's needs.

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 clearly states the tool's purpose: converting datetime to unixtime with an example. It specifies the verb 'convert' and the resource 'datetime time to unixtime', making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'convert_unix_to_datetime' or 'get_unixtime', which prevents a score 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?

The description provides no guidance on when to use this tool versus alternatives. It lacks context such as when this conversion is needed, prerequisites, or comparisons to sibling tools like 'convert_unix_to_datetime' or 'get_unixtime'. This absence of usage instructions leaves the agent without clear direction.

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

convert_unix_to_datetimeC

Convert unixtime to datetime time (e.g. 1746627290 to 2025-01-01 01:01:01)

ParametersJSON Schema

Name	Required	Description	Default
`unixtime`	Yes
`timezone`	No
`isISO`	No

TDQS

C2.8/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. It describes the basic conversion behavior but omits key details: default timezone handling, the effect of the isISO parameter, error handling for invalid inputs, and output format specifics. For a tool with 3 parameters and no annotation coverage, this is insufficient.

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?

The description is extremely concise and front-loaded, using a single sentence with a clear example. Every word earns its place, making it easy to scan and understand the core purpose without unnecessary details.

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

Completeness2/5

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

Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the output format beyond the example, how parameters interact, or potential errors. For a conversion tool with multiple options, more context is needed to ensure correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only mentions the unixtime parameter implicitly via the example, but provides no information about timezone (e.g., format like 'UTC' or 'America/New_York') or isISO (e.g., whether it outputs ISO 8601 format). This leaves two parameters undocumented, failing to address the coverage gap.

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 clearly states the tool's function: converting Unix time to datetime format, with a specific example (1746627290 to 2025-01-01 01:01:01). It distinguishes from siblings like convert_datetime_to_unix by specifying the direction of conversion. However, it doesn't explicitly mention all siblings, so it's not a perfect 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?

The description provides no guidance on when to use this tool versus alternatives like get_current_date_time or get_unixtime. It lacks context about scenarios where Unix time conversion is needed, such as processing timestamps from APIs or logs. No exclusions or prerequisites are mentioned.

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

get_current_date_timeA

Get the current date and time (e.g. 2025-01-01 01:01:01)

ParametersJSON Schema

Name	Required	Description	Default
`timezone`	No

TDQS

A3.9/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 full burden. It states what the tool returns (current datetime with example format) but lacks behavioral details like whether it's real-time, if it uses system time, error handling, or performance characteristics.

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?

Single sentence with zero waste, front-loaded with the core purpose. The example format is efficiently included as parenthetical clarification.

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 tool with 1 parameter, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and output format but lacks parameter documentation and behavioral context that would be helpful given the absence of structured fields.

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 0%, but the description does not mention the 'timezone' parameter at all. However, with only 1 parameter and no schema descriptions, the baseline is high. The description adds value by specifying the output format example, but misses parameter context.

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 clearly states the verb 'Get' and the resource 'current date and time', with a specific example format. It distinguishes from siblings like get_current_date_time_iso (ISO format) and get_unixtime (Unix timestamp).

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 implies usage for obtaining current datetime in a specific format, but does not explicitly state when to use this vs. alternatives like get_current_date_time_iso or get_unixtime. The context is clear but lacks explicit sibling differentiation.

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

get_current_date_time_isoB

Get ISO 8601 time. (e.g. 2025-05-07T23:03:27+09:00)

ParametersJSON Schema

Name	Required	Description	Default
`timezone`	No

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns current time in ISO 8601 format with an example, but doesn't mention if it's read-only, requires permissions, has rate limits, or how it handles the optional timezone parameter. This leaves gaps in understanding the tool's behavior beyond basic output format.

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?

The description is extremely concise—a single sentence with a helpful example. It's front-loaded with the core purpose and wastes no words, making it easy for an agent to parse quickly. Every element earns its place.

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?

Given the tool's low complexity (single optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the output format with an example, but lacks details on parameter usage, behavioral traits, or differentiation from siblings. For a simple time-fetching tool, it's passable but leaves room for improvement in context.

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 input schema has one parameter 'timezone' with 0% description coverage. The tool description doesn't mention parameters at all, failing to compensate for the schema gap. However, with only one optional parameter, the baseline is moderate, but the description adds no value beyond what the bare schema provides.

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 clearly states the verb 'Get' and the resource 'ISO 8601 time', with an example format provided. It distinguishes from siblings like 'get_current_date_time' by specifying the ISO format, though it doesn't explicitly contrast with all siblings. The purpose is specific and actionable.

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 is provided on when to use this tool versus alternatives like 'get_current_date_time' or 'get_unixtime'. The description implies usage for obtaining current time in ISO format, but lacks explicit when/when-not instructions or named alternatives, leaving the agent to infer based on format differences.

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

get_elapsed_timeB

Get the difference time between two datetimes (e.g. 2025-01-01 01:01:01 and 2025-01-02 02:02:02)

ParametersJSON Schema

Name	Required	Default
`from`	Yes
`to`	Yes
`unit`	No	millisecond

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about error handling (e.g., invalid date formats), timezone considerations, rounding behavior, or output format. The example helps but doesn't cover behavioral traits.

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?

The description is a single, efficient sentence with a helpful example. It's front-loaded with the core purpose and uses minimal words to convey the essential information without any wasted text.

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?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on parameter usage, error handling, and output format. For a time calculation tool, more context on date-time formats and result interpretation would be helpful.

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 description mentions 'two datetimes' which maps to the 'from' and 'to' parameters, and the example shows date-time strings. However, with 0% schema description coverage, it doesn't explain the 'unit' parameter or its enum values. The description adds some meaning but doesn't fully compensate for the schema coverage gap.

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 clearly states the tool's purpose: 'Get the difference time between two datetimes' with a specific example. It uses a clear verb ('Get') and resource ('difference time'), but doesn't explicitly differentiate from sibling tools like 'get_current_date_time' or 'convert_datetime_to_unix' which serve different purposes.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or suggest scenarios where this tool is preferred over others like 'get_current_date_time' for current time or conversion tools for format changes.

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

get_timezoneB

Get timezone (e.g. Asia/Tokyo)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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. The description only states what the tool returns ('timezone') without explaining how it determines which timezone, whether it requires any context or permissions, what format the return value uses, or whether it's static or dynamic. For a tool with zero annotation coverage, this is insufficient behavioral context.

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?

The description is extremely concise (5 words plus an example) and front-loaded with the core purpose. Every word earns its place - 'Get' specifies the action, 'timezone' specifies the resource, and the example provides helpful clarification. No wasted words or unnecessary elaboration.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what kind of timezone is returned (system default? user preference? based on location?), the return format, or any behavioral characteristics. For a tool that might have implementation nuances (e.g., server timezone vs. client timezone), more context is needed despite the simple parameterless design.

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?

The tool has zero parameters, and schema description coverage is 100% (though the schema is empty). The description appropriately doesn't discuss parameters since none exist. It focuses on the return value ('timezone') which is correct for a parameterless tool. Baseline for zero parameters is 4.

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 clearly states the tool's purpose with a specific verb ('Get') and resource ('timezone'), and provides a helpful example ('Asia/Tokyo'). It distinguishes from siblings by focusing on timezone retrieval rather than datetime conversion or elapsed time calculations. However, it doesn't explicitly differentiate from all siblings (like get_current_date_time which might also return timezone).

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?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for datetime operations (convert_datetime_to_unix, get_current_date_time, etc.), there's no indication whether this returns the system timezone, a user's timezone, or supports location-based lookup. No explicit when/when-not or alternative recommendations are provided.

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

get_unixtimeB

Get unixtime (e.g. 1746627290)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/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 full burden. It states what the tool returns ('unixtime') but doesn't disclose behavioral traits like whether it returns current system time, requires network access, has rate limits, or provides timezone context. The example suggests it returns a numeric timestamp, but that's implied by 'unixtime' itself.

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?

The description is extremely concise (one short sentence with a helpful example) and front-loaded with the core purpose. Every word earns its place—'Get' establishes the action, 'unixtime' specifies the resource, and the example clarifies the format without redundancy.

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?

Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It tells the agent what the tool returns but lacks context about time source, precision, or differences from sibling tools. For a basic time-fetching tool, this might suffice, but gaps remain in behavioral transparency.

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?

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the output. This meets the baseline of 4 for zero-parameter tools.

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 clearly states the verb ('Get') and resource ('unixtime'), providing a concrete example (1746627290) that illustrates the output format. However, it doesn't differentiate from siblings like 'get_current_date_time' or 'convert_datetime_to_unix', which might return similar time-related data in different formats.

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?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_current_date_time' (which might return human-readable time) and conversion tools, the agent has no indication whether this tool is for current time, a specific time, or general Unix time retrieval.

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. Dates show when Glama detected each change.

7 tool updatesAug 14, 2025
- First observedconvert_datetime_to_unix
- First observedconvert_unix_to_datetime
- First observedget_current_date_time
- First observedget_current_date_time_iso
- First observedget_elapsed_time
- First observedget_timezone
- First observedget_unixtime

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap. For example, convert_datetime_to_unix and convert_unix_to_datetime are inverse operations, get_current_date_time and get_current_date_time_iso provide different formats, and get_elapsed_time calculates differences, making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., convert_datetime_to_unix, get_current_date_time). The naming is predictable and readable throughout the set, with no deviations in style or convention.

Tool Count5/5

With 7 tools, the count is well-scoped for a time utility server. Each tool serves a specific function in time conversion, retrieval, and calculation, with no redundancy or missing essential operations, making the set efficient and focused.

Completeness4/5

The tool set covers core time operations like conversion, current time retrieval, elapsed time calculation, and timezone handling. Minor gaps might include operations like timezone conversion or date arithmetic, but agents can work around these with the provided tools.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

tick-mcp A
io.github.Cocabadger
A time server that keeps your AI honest about time. Real clock + drift guard, zero dependencies.
Developer Tools
226
time-mcp A
io.github.jmavid
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Developer Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

DateTime MCP Server
Developer Tools
TakanariShimbo
A
license
B
quality
D
maintenance
A Model Context Protocol server that provides tools to get the current date and time in various formats, supporting different timezones and custom formatting options.
Updated a year ago (2025-06-28 23:02 UTC)
1
29
1
MIT
Time MCP Server
Developer Tools
ssinha3
A
license
B
quality
D
maintenance
A Model Context Protocol server that provides time and timezone conversion capabilities, enabling LLMs to get current time information and perform timezone conversions using IANA timezone names.
Updated a year ago (2025-06-27 00:14 UTC)
2
MIT
Time
Developer Tools App Automation
TheoBrigitte
A
license
Not graded
quality
C
maintenance
The Time MCP Server is a Model Context Protocol (MCP) server that provides AI assistants and other MCP clients with standardized tools to perform time and date-related operations. This server acts as a bridge between AI tools and a robust time-handling back
Updated 5 months ago (2026-03-30 10:02 UTC)
184
25
MIT
Temporal Awareness MCP Server
pmbstyle
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that provides AI agents with comprehensive temporal awareness and time calculation capabilities.
Updated a year ago (2025-07-18 01:03 UTC)
3
MIT

Appeared in Searches

ManicTime - Time Tracking Software

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/t-shiratori/time-tools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server