A
licenseB
qualityD
maintenanceA lightweight mcp server that tells you exactly what time is it based on your IP.
1
9
MIT
MCP Simple Timeserver
by andybrandt
The MCP Simple Timeserver enables Claude to access accurate time information through two key capabilities:
Get Local Time and Timezone: Retrieve the current local time and timezone details from the user's machine, helping Claude understand the user's local context.
Get UTC Time from NTP Server: Fetch precise Coordinated Universal Time (UTC) from an NTP server, with the option to specify a custom NTP server address for universal time reference.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Simple Timeserverwhat time is it locally?"
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.
MCP Simple Timeserver
One of the strange design decisions Anthropic made was depriving Claude of timestamps for messages sent by the user in claude.ai or current time in general. Poor Claude can't tell what time it is! mcp-simple-timeserver is a simple MCP server that fixes that.
Available Tools
This server provides the following tools:
Tool | Description |
| Returns the current local time, day of week, and timezone from the user's machine |
| Returns accurate UTC time from an NTP time server |
| Returns current time with optional location, timezone, and calendar conversions |
| Calculates duration between two dates/times (countdowns, elapsed time) |
| Returns public holidays (and optionally school holidays) for a country |
| Checks if a specific date is a holiday in a given country or city |
All tools (except get_local_time) use accurate time from NTP servers. If NTP is unavailable, they gracefully fall back to local server time with a notice.
Location Support via get_current_time
The get_current_time tool supports location parameters to get local time anywhere in the world:
Parameter | Description | Example |
| City name (primary use case) |
|
| Country name or ISO code |
|
| IANA timezone or UTC offset |
|
Priority: timezone > city > country. When location is provided, the response includes local time, timezone info, UTC offset, and DST status.
If today is a public holiday at the specified location, it will be shown in the output.
Calendar Support via get_current_time
The get_current_time tool also accepts an optional calendar parameter with a comma-separated list of calendar formats:
Calendar | Description |
| Unix timestamp (seconds since 1970-01-01) |
| ISO 8601 week date (e.g., |
| Islamic/Hijri lunar calendar |
| Japanese Era calendar (returns both English and Kanji) |
| Hebrew/Jewish calendar (returns both English and Hebrew, includes holidays) |
| Persian/Jalali calendar (returns both English and Farsi) |
Example: get_current_time(city="Tokyo", calendar="japanese") returns Tokyo local time with Japanese Era calendar.
Time Distance Calculation via calculate_time_distance
Calculate duration between two dates or times:
Parameter | Description | Example |
| Start date (ISO 8601 or "now") |
|
| End date (ISO 8601 or "now") |
|
| Output format |
|
| Count only Mon-Fri (date-based, inclusive) |
|
| Also exclude public holidays (requires country/city) |
|
Location parameters (city, country, timezone) can also be used to specify timezone context.
When business_days=true, time-of-day is ignored and dates are counted as full days (inclusive endpoints).
The unit parameter is ignored in this mode. Holidays are excluded only when they fall on weekdays.
Example: calculate_time_distance(from_date="now", to_date="2025-12-31") returns a countdown to New Year's Eve.
Example: calculate_time_distance(from_date="2026-01-26", to_date="2026-01-30", business_days=true, exclude_holidays=true, city="Sydney") returns the number of business days in that range.
Holiday Information via get_holidays and is_holiday
Get public and school holiday information for ~119 countries:
get_holidays parameters:
Parameter | Description | Example |
| Country name or ISO code (required) |
|
| Year to get holidays for (default: current year) |
|
| Include school vacation periods |
|
is_holiday parameters:
Parameter | Description | Example |
| Country name or ISO code |
|
| City name for region-specific info |
|
| Date to check in ISO format (default: today) |
|
Regional School Holidays: When using the city parameter with is_holiday, school holidays are filtered to show only those affecting the specific region. This is particularly useful in countries where school holidays vary by region (e.g., Polish voivodeships, German Bundesländer, Spanish autonomous communities).
Example: is_holiday(city="Warsaw", date="2026-01-19") returns school holiday information specific to the Mazowieckie voivodeship.
Data Sources:
Public holidays: Nager.Date API (119 countries)
School holidays: OpenHolidaysAPI (36 countries, mostly European)
Related MCP server: DateTime MCP Server
Installation
Installing via Smithery
To install Simple Timeserver for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install mcp-simple-timeserver --client claudeManual Installation
First install the module using:
pip install mcp-simple-timeserver
Then configure in MCP client - the Claude desktop app.
Under Mac OS this will look like this:
"mcpServers": {
"simple-timeserver": {
"command": "python",
"args": ["-m", "mcp_simple_timeserver"]
}
}Under Windows you have to check the path to your Python executable using where python in the cmd (Windows command line).
Typical configuration would look like this:
"mcpServers": {
"simple-timeserver": {
"command": "C:\\Users\\YOUR_USERNAME\\AppData\\Local\\Programs\\Python\\Python311\\python.exe",
"args": ["-m", "mcp_simple_timeserver"]
}
}Web Server Variant
This project also includes a network-hostable version that can be deployed as a standalone web server. For instructions on how to run and deploy it, please see the Web Server Deployment Guide.
Or you can simply use my server by adding it under https://mcp.andybrandt.net/timeserver to Claude and other tools that support MCP.
Available Tools
2 toolsget_local_timeGet Local Time and TimezoneARead-only
Returns the current local time and timezone information from your local machine. This helps you understand what time it is for the user you're assisting.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by specifying that the data comes from 'your local machine' and its purpose for assisting users, which provides useful context beyond the annotations. However, it does not disclose additional behavioral traits like performance or error handling.
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 two sentences, front-loaded with the core functionality and followed by a brief explanation of its utility. Every sentence adds value without redundancy, making it efficient and well-structured.
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 tool's low complexity (0 parameters, read-only, with output schema), the description is complete enough for its purpose. It explains what the tool returns and why it's useful, and with an output schema present, it does not need to detail return values. However, it could be more explicit about sibling differentiation.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate. Baseline is 4 for zero parameters, as the description does not need to compensate for any gaps.
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 ('Returns') and resource ('current local time and timezone information from your local machine'). It distinguishes from the sibling 'get_utc' by specifying 'local' time, though not explicitly naming the alternative. The description avoids tautology by explaining what the tool does rather than restating the name.
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 implies usage context by stating 'This helps you understand what time it is for the user you're assisting,' which suggests when to use it. However, it does not explicitly state when to use this tool versus the sibling 'get_utc' or provide any exclusions. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_utcGet UTC Time from an NTP ServerARead-only
Returns accurate UTC time from an NTP server. This provides a universal time reference regardless of local timezone.
:param server: NTP server address (default: pool.ntp.org)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | pool.ntp.org |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context about accuracy ('accurate UTC time') and the universal time reference aspect, though it doesn't mention potential network dependencies or rate limits.
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 efficiently structured with three sentences that each add value: stating the core function, explaining the benefit, and clarifying the parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), presence of readOnlyHint annotation, and existence of an output schema, the description provides complete context for effective use without needing to explain return values.
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?
With 0% schema description coverage, the description compensates by explaining the 'server' parameter's purpose ('NTP server address') and default value, adding meaningful semantics beyond the bare 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 specific action ('Returns accurate UTC time') and resource ('from an NTP server'), distinguishing it from the sibling tool 'get_local_time' by emphasizing universal time reference regardless of local timezone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('provides a universal time reference regardless of local timezone'), which implicitly differentiates it from 'get_local_time', but doesn't explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.9/5.0
Disambiguation5/5
The two tools have clearly distinct purposes: get_local_time provides local time with timezone information, while get_utc provides universal time from an NTP server. There is no overlap or ambiguity between these functions.
Naming Consistency5/5
Both tools follow a consistent verb_noun naming pattern (get_local_time, get_utc) with the same verb 'get' and clear noun objects. The naming is perfectly uniform and predictable.
Tool Count3/5
With only 2 tools, the server feels somewhat thin for a timeserver domain. While the tools cover basic time retrieval, additional functionality like time conversion, formatting, or scheduling might be expected but is missing.
Completeness3/5
The server provides core time retrieval functions (local and UTC), but lacks operations for time manipulation, conversion between timezones, or date calculations. These gaps limit the server's utility for more complex time-related tasks.
Maintenance
ActivityInactive
ResponsivenessResponsive
Related MCP Connectors
MCP server providing attendance data queries via the CloudTime API.
A simple MCP server built with FastMCP and python
Related MCP Servers
- FlicenseBqualityDmaintenanceA simple MCP server that provides accurate date and time information to Claude models, ensuring they always use the correct current date and time when creating time-sensitive content.3
- FlicenseNot gradedqualityDmaintenanceA minimal MCP server that provides current time information with configurable timezone support set on the client side.
- AlicenseAqualityFmaintenanceMCP server providing various date/time functions including current time, timezone conversion, and relative time calculations. Supports both local stdio and remote HTTP access via Cloudflare Workers.64902MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/andybrandt/mcp-simple-timeserver'
If you have feedback or need assistance with the MCP directory API, please join our Discord server