What can you do with this server?

This server provides LLMs with comprehensive time awareness and manipulation capabilities: * Get current time - Retrieve current date and time in various formats (12/24-hour, different date formats) with optional timezone specification * Calculate relative time - Determine how much time has passed or will pass relative to a specific date/time (e.g., "2 hours ago", "in 3 days") * Convert timestamps - Generate Unix timestamps from date/time strings for precise time calculations * Get days in month - Find out how many days are in a specified month or the current month * Convert between timezones - Transform times from one IANA timezone to another (e.g., New York to Tokyo) * Get week numbers - Determine the week and ISO week numbers of the year for any given date These tools enable LLMs to answer questions about current time, perform time calculations, handle timezone conversions, and work with various date/time formats.

Which integrations are available for this server?

Allows integration with Windsurf in Codeium, enabling time awareness capabilities for LLMs within the Codeium environment.

How do I use time-mcp?

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-mcp what time is it in Tokyo right now?" 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.

en es ja ko zh

time-mcp

by yokingma

Overview Schema Related Servers Score Discussions

JavaScript

Remote

🚀 Time MCP Server: Giving LLMs Time Awareness Capabilities

A Model Context Protocol (MCP) server implementation that allows LLMs to have time awareness capabilities.

Tools

current_time: Get current time (UTC and local time)
relative_time: Get relative time
get_timestamp: Get timestamp for the time
days_in_month: Get days in month
convert_time: Convert time between timezones
get_week_year: Get week and isoWeek of the year

Related MCP server: Time MCP Server

Installation

Installing via Smithery

To install time-mcp for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @yokingma/time-mcp --client claude

Manually install (Optional)

npm install -g time-mcp

using npx

npx -y time-mcp

Running on Claude Code

To add time-mcp to Claude Code, use the following command:

claude mcp add time-mcp -- npx -y time-mcp

To verify the installation:

claude mcp list

You should see time-mcp listed with a ✓ Connected status.

Usage in Claude Code

Once installed, you can use time-mcp tools in your conversations with Claude Code. For example:

"What time is it now?"
"Convert 2:00 PM from New York to Tokyo time"
"How many days are in this month?"
"What week of the year is it?"

The time-mcp server will automatically provide accurate time information to Claude.

Running on Cursor

Your mcp.json file will look like this:

{
  "mcpServers": {
    "time-mcp": {
      "command": "npx",
      "args": ["-y", "time-mcp"]
    }
  }
}

Running on Windsurf

Add this to your ./codeium/windsurf/model_config.json file:

{
  "mcpServers": {
    "time-mcp": {
      "command": "npx",
      "args": ["-y", "time-mcp"]
    }
  }
}

License

MIT License - see LICENSE file for details.

Available Tools

6 tools

convert_timeB

Convert time between timezones.

ParametersJSON Schema

Name	Required	Description
`time`	Yes	Date and time in 24-hour format. e.g. 2025-03-23 12:30:00
`sourceTimezone`	Yes	The source timezone. IANA timezone name, e.g. Asia/Shanghai
`targetTimezone`	Yes	The target timezone. IANA timezone name, e.g. Europe/London

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description is the sole source of behavioral information, but it only states the basic function. It does not disclose behavior regarding invalid inputs, DST handling, output format, or error conditions.

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 a single, concise sentence that directly states the purpose with no redundancy. It could have included more detail without sacrificing conciseness, hence a 4 rather than 5.

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?

While the input parameters are well-documented via the schema, there is no output description or mention of error handling, and the description does not differentiate from siblings beyond the name. Given the tool's simplicity, this is adequate but not complete.

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 already has 100% coverage with clear descriptions for all three parameters. The tool description adds no additional semantic value beyond what the schema provides, meriting a baseline score of 3.

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 'Convert time between timezones' clearly states the action (convert) and the resource (time between timezones), effectively distinguishing it from sibling tools like current_time or days_in_month.

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, nor does it mention any prerequisites or limitations, leaving the agent without clear usage context.

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

current_timeA

Get the current date and time.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	The format of the time	YYYY-MM-DD HH:mm:ss
`timezone`	No	The timezone of the time, IANA timezone name, e.g. Asia/Shanghai

TDQS

A4/5.0

Behavior4/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 straightforwardly describes the tool's action, but does not specify the return format or default timezone behavior, though these are partially covered by the schema.

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 concise sentence that is front-loaded with the key action. No unnecessary words or information.

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 tool with no output schema and full schema parameter coverage, the description is adequately complete. It could mention that the output is a string, but that is implied by the format parameter.

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 the schema fully documents both parameters. The description adds no additional parameter-level detail beyond what is already in the schema.

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 'Get the current date and time' clearly states the verb and resource. It distinguishes from siblings like convert_time or get_timestamp 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use or avoid this tool versus alternatives. Its purpose is clear, but no comparative context is given.

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

days_in_monthA

Get the number of days in a month. If no date is provided, get the number of days in the current month.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	The date to get the days in month. Format: YYYY-MM-DD

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It clearly states the primary behavior (returns days in month) and the default behavior (current month if no date). It does not discuss error handling or edge cases, but the operation is simple and safe.

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 concise sentences, no wasted words, essential information front-loaded. Every sentence adds value.

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?

Given the simplicity and no output schema, the description adequately covers the tool's functionality. It describes the input and output behavior, though it could mention that the return is an integer. Still, it's sufficient for correct usage.

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 schema covers the single parameter with format description. The tool description adds value by clarifying that the parameter is optional and explaining the default behavior when omitted, which goes beyond the schema.

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 tool's purpose: get the number of days in a month, with a specific verb 'Get' and resource 'days in a month'. It distinguishes from sibling tools like convert_time or current_time, which handle different time operations.

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 implicitly suggests usage when needing days in a month, and explicitly notes the behavior when no date is provided. It does not explicitly mention alternatives, but the context makes the use case clear.

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

get_timestampD

Get the timestamp for the time.

ParametersJSON Schema

Name	Required	Description	Default
`time`	No	The time to get the timestamp. Format: YYYY-MM-DD HH:mm:ss.SSS

TDQS

D1.8/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, error responses, or whether it returns seconds or milliseconds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence but is under-specified; it does not earn its place as it fails to clarify the output or usage context.

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?

With no output schema and no annotations, the description should explain the return value (e.g., timestamp format). It only states the function without specifying output, leaving the tool incomplete 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?

Schema coverage is 100% and the parameter 'time' already has a clear description with format. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the timestamp for the time' is tautological as it restates the tool name without specifying what a timestamp is or how it differs from sibling tools like convert_time or current_time. It does not indicate output format (e.g., epoch seconds).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/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 its siblings (convert_time, current_time, etc.) or any context about prerequisites or typical use cases.

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

get_week_yearB

Get the week and isoWeek of the year.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	The date to get the week and isoWeek of the year. e.g. 2025-03-23

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 full burden. It does not disclose whether the tool is read-only, has side effects, or requires specific input validation. The description is minimal and offers no behavioral insight beyond the basic 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?

The description is a single sentence that efficiently conveys the purpose. No extraneous information, front-loaded with the core action.

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 one parameter and no output schema or annotations, the description is adequate but not rich. It does not explain what 'week' means (e.g., week number starting from 1) or the return format. However, the example in the schema helps. Middle ground.

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 already provides full coverage for the single parameter (date) with a clear description and example. The tool description adds no additional semantic value beyond what the schema provides. Baseline score of 3 is appropriate.

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 it gets the week and ISO week of the year, which is a specific verb and resource. It distinguishes itself from sibling tools like current_time or convert_time which are about time conversion or current time. However, it could be slightly more precise by clarifying that it returns both week number and ISO week number.

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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives like get_timestamp or relative_time. There is no mention of prerequisites, exclusions, or context.

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

relative_timeC

Get the relative time from now.

ParametersJSON Schema

Name	Required	Description	Default
`time`	Yes	The time to get the relative time from now. Format: YYYY-MM-DD HH:mm:ss

TDQS

C2.9/5.0

Behavior2/5

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

Lacking annotations, the description should fully disclose behavior. It only states the action without explaining what 'relative time' means, how time zones are handled, or edge cases (e.g., future vs past times).

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?

One concise sentence with no extraneous information. Every word is necessary, though brevity sacrifices completeness.

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?

The tool has one parameter and no output schema. The description fails to explain the return value (e.g., format of relative time), leaving a significant gap in understanding.

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% with description for the 'time' parameter. The tool description adds no extra meaning beyond what is already in the schema, earning a baseline score.

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?

Description clearly states verb ('Get') and resource ('relative time'), and distinguishes from siblings like 'current_time' and 'convert_time'. However, it does not specify the output format, which could be ambiguous.

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 tool versus alternatives. The description does not mention when-not or provide context for selection among siblings.

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.

6 tool updatesv1.0.6May 1, 2026
- Addedconvert_time
- Addedcurrent_time
- Addeddays_in_month
- Addedget_timestamp
- Addedget_week_year
- Addedrelative_time
6 tool updatesv1.0.5May 1, 2026
- Removedconvert_time
- Removedcurrent_time
- Removeddays_in_month
- Removedget_timestamp
- Removedget_week_year
- Removedrelative_time
6 tool updatesv1.0.0Aug 18, 2025
- First observedconvert_time
- First observedcurrent_time
- First observeddays_in_month
- First observedget_timestamp
- First observedget_week_year
- First observedrelative_time

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct time-related operation with no overlap. convert_time, current_time, days_in_month, get_timestamp, get_week_year, and relative_time all serve unique purposes.

Naming Consistency4/5

Names follow snake_case and are mostly descriptive, but there is slight inconsistency: some start with 'get' (get_timestamp, get_week_year) while others are adjective+noun (current_time) or verb+noun (convert_time).

Tool Count5/5

Six tools is an appropriate number for a time utility server, covering essential operations without being excessive or minimal.

Completeness4/5

Common time operations are covered (conversion, current time, days in month, timestamp, week/year, relative time). Missing features like date arithmetic or time difference are minor gaps that don't hinder typical use.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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

time-mcp A
io.github.jmavid
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Developer Tools
2
time A
pro.worldclock
A real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Developer Tools
52
temporal-mcp A
io.github.MirrorEthic
Wall-clock awareness for LLM agents. Two tools: elapsed-time-between-turns + day rollover detection.
Agent Orchestration Autonomous Agents
223
chrono-mcp A
io.github.nexus-api-lab
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
Developer Tools Calendar Management
2

Related MCP Servers

Time MCP Server
ampcome-mcps
A
license
B
quality
D
maintenance
Gives large language models time awareness capabilities through various time-related functions including current time retrieval, timezone conversion, and relative time calculations.
Updated a year ago (2025-07-14 05:21 UTC)
6
1,823
MIT
Time MCP Server
Developer Tools
dumyCq
A
license
B
quality
D
maintenance
Provides time and timezone functionality for LLMs, enabling them to get current time information across different timezones and convert times between zones.
Updated a year ago (2025-08-15 01:01 UTC)
2
MIT
Time MCP Server
Search
CarterPape
A
license
Not graded
quality
D
maintenance
Provides current time information and timezone conversion capabilities using IANA timezone names and automatic system detection. It enables LLMs to fetch current times across different regions and convert specific times between timezones.
Updated a year ago (2025-06-21 23:27 UTC)
MIT
mcp-timer-server
Developer Tools
scottyphillips
A
license
A
quality
C
maintenance
Provides accurate system time to LLM applications with multi-timezone support via a simple tool call.
Updated 3 months ago (2026-06-14 01:00 UTC)
1
MIT

Appeared in Searches

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/yokingma/time-mcp'

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