Time MCP Server
Time MCP Server
시간 및 시간대 변환 기능을 제공하는 Model Context Protocol 서버입니다. 이 서버는 LLM이 IANA 시간대 이름을 사용하여 현재 시간 정보를 얻고 시간대 변환을 수행할 수 있도록 하며, 시스템 시간대를 자동으로 감지합니다.
사용 가능한 도구
get_current_time- 특정 시간대 또는 시스템 시간대의 현재 시간을 가져옵니다.필수 인자:
timezone(string): IANA 시간대 이름 (예: 'America/New_York', 'Europe/London')
convert_time- 시간대 간 시간을 변환합니다.필수 인자:
source_timezone(string): 소스 IANA 시간대 이름time(string): 24시간 형식(HH:MM)의 시간target_timezone(string): 대상 IANA 시간대 이름
설치
uv 사용 (권장)
uv를 사용할 때는 특별한 설치가 필요 없습니다.
uvx를 사용하여 mcp-server-time을 직접 실행합니다.
uvx mcp-server-timePIP 사용
또는 pip를 통해 mcp-server-time을 설치할 수 있습니다:
pip install mcp-server-time설치 후에는 다음을 사용하여 스크립트로 실행할 수 있습니다:
python -m mcp_server_timeRelated MCP server: Time MCP Server
설정
Claude.app용 설정
Claude 설정에 추가하세요:
{
"mcpServers": {
"time": {
"command": "uvx",
"args": ["mcp-server-time"]
}
}
}{
"mcpServers": {
"time": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "LOCAL_TIMEZONE", "mcp/time"]
}
}
}{
"mcpServers": {
"time": {
"command": "python",
"args": ["-m", "mcp_server_time"]
}
}
}Zed용 설정
Zed settings.json에 추가하세요:
"context_servers": [
"mcp-server-time": {
"command": "uvx",
"args": ["mcp-server-time"]
}
],"context_servers": {
"mcp-server-time": {
"command": "python",
"args": ["-m", "mcp_server_time"]
}
},VS Code용 설정
빠른 설치를 위해 아래의 원클릭 설치 버튼 중 하나를 사용하세요...
수동 설치를 위해 VS Code의 사용자 설정(JSON) 파일에 다음 JSON 블록을 추가하세요. Ctrl + Shift + P를 누르고 Preferences: Open User Settings (JSON)을 입력하면 됩니다.
선택적으로 작업 영역의 .vscode/mcp.json 파일에 추가할 수 있습니다. 이렇게 하면 구성을 다른 사람과 공유할 수 있습니다.
mcp.json파일을 사용할 때는mcp키가 필요합니다.
{
"mcp": {
"servers": {
"time": {
"command": "uvx",
"args": ["mcp-server-time"]
}
}
}
}{
"mcp": {
"servers": {
"time": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/time"]
}
}
}
}Zencoder용 설정
Zencoder 메뉴(...)로 이동합니다.
드롭다운 메뉴에서
Agent Tools를 선택합니다.Add Custom MCP를 클릭합니다.아래에서 이름과 서버 구성을 추가하고
Install버튼을 반드시 누르세요.
{
"command": "uvx",
"args": ["mcp-server-time"]
}사용자 지정 - 시스템 시간대
기본적으로 서버는 시스템의 시간대를 자동으로 감지합니다. 구성의 args 목록에 --local-timezone 인자를 추가하여 이 값을 재정의할 수 있습니다.
예:
{
"command": "python",
"args": ["-m", "mcp_server_time", "--local-timezone=America/New_York"]
}상호 작용 예시
현재 시간 가져오기:
{
"name": "get_current_time",
"arguments": {
"timezone": "Europe/Warsaw"
}
}응답:
{
"timezone": "Europe/Warsaw",
"datetime": "2024-01-01T13:00:00+01:00",
"is_dst": false
}시간대 간 시간 변환:
{
"name": "convert_time",
"arguments": {
"source_timezone": "America/New_York",
"time": "16:30",
"target_timezone": "Asia/Tokyo"
}
}응답:
{
"source": {
"timezone": "America/New_York",
"datetime": "2024-01-01T12:30:00-05:00",
"is_dst": false
},
"target": {
"timezone": "Asia/Tokyo",
"datetime": "2024-01-01T12:30:00+09:00",
"is_dst": false
},
"time_difference": "+13.0h",
}디버깅
MCP 인스펙터를 사용하여 서버를 디버깅할 수 있습니다. uvx 설치의 경우:
npx @modelcontextprotocol/inspector uvx mcp-server-time또는 패키지를 특정 디렉터리에 설치했거나 해당 패키지를 개발 중인 경우:
cd path/to/servers/src/time
npx @modelcontextprotocol/inspector uv run mcp-server-timeClaude에게 물어볼 수 있는 질문 예시
"지금 몇 시인가요?" (시스템 시간대를 사용합니다)
"도쿄는 지금 몇 시인가요?"
"뉴욕이 오후 4시일 때 런던은 몇 시인가요?"
"도쿄 시간 오전 9시 30분을 뉴욕 시간으로 변환해 주세요."
빌드
Docker 빌드:
cd src/time
docker build -t mcp/time .기여
mcp-server-time을 확장하고 개선하는 데 도움이 되는 기여를 환영합니다. 새로운 시간 관련 도구를 추가하거나, 기존 기능을 향상시키거나, 문서를 개선하려는 경우에도 여러분의 기여는 소중합니다.
다른 MCP 서버 및 구현 패턴의 예는 다음을 참조하세요: https://github.com/modelcontextprotocol/servers
풀 리퀘스트를 환영합니다! mcp-server-time을 더욱 강력하고 유용하게 만들 수 있는 새로운 아이디어, 버그 수정, 개선 사항을 자유롭게 기여해 주세요.
라이선스
mcp-server-time은 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 이용약관에 따라 소프트웨어를 자유롭게 사용, 수정, 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
Available Tools
2 toolsconvert_timeC
Convert time between timezones
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | Time to convert in 24-hour format (HH:MM) | |
| source_timezone | Yes | Source IANA timezone name (e.g., 'America/New_York', 'Europe/London'). Use 'Etc/UTC' as local timezone if no source timezone provided by the user. | |
| target_timezone | Yes | Target IANA timezone name (e.g., 'Asia/Tokyo', 'America/San_Francisco'). Use 'Etc/UTC' as local timezone if no target timezone provided by the user. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose any behavioral traits such as how time zones are handled, invalid inputs, or daylight saving time. The description is minimal and adds no transparency beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded. However, it could include more useful information without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not mention return format, error handling, or edge cases. For a time zone conversion tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Convert time between timezones', conveying the verb and resource. However, it does not differentiate from the sibling tool 'get_current_time', which might also involve time zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description is a single phrase with no context about prerequisites or when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_current_timeC
Get current time in a specific timezones
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | Yes | IANA timezone name (e.g., 'America/New_York', 'Europe/London'). Use 'Etc/UTC' as local timezone if no timezone provided by the user. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get current time' without disclosing output format, time source, or any behavioral details like handling of invalid timezones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence but grammatically flawed ('timezones'). It is concise but lacks clarity and proper structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 omits critical context such as return format, time source (server vs user), and error handling. Incomplete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full description of the 'timezone' parameter with examples (100% coverage). The tool description adds no additional semantic value beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets current time in a specific timezone, but the grammar ('timezones') slightly reduces clarity. It distinguishes from sibling 'convert_time' by focusing on current time retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs the sibling 'convert_time' or any exclusion criteria. The description does not indicate context-specific usage.
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.
2 tool updates
v1.0.3- First observed
convert_time - First observed
get_current_time
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one retrieves the current time for a given timezone, and the other converts a specified time between timezones. There is no overlap or ambiguity between them.
Both tools follow the same verb_noun snake_case pattern: get_current_time and convert_time. The naming is predictable and clearly indicates the action and target.
With only two tools, the server feels minimal for its domain, though both tools are essential and focused. The count is borderline but not unreasonable for a simple timezone utility.
The core time-related operations are covered: getting current time and converting between timezones. A list of supported timezones would be a minor useful addition, but agents can work reasonably well without it.
Maintenance
Related MCP Connectors
A real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Current time in any IANA time zone, plus the full time-zone list. Via timeapi.io.
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides time and timezone functionality for LLMs, enabling them to get current time information across different timezones and convert times between zones.2MIT
- AlicenseBqualityDmaintenanceProvides current time information and timezone conversion capabilities using IANA timezone names. Enables LLMs to get current time in any timezone and convert times between different timezones with automatic system timezone detection.2MIT
- AlicenseAqualityDmaintenanceProvides LLMs with current date and time information across any timezone, with configurable defaults and support for IANA timezone identifiers.111 npm3Apache 2.0
- AlicenseBqualityDmaintenanceProvides current time information and timezone conversion capabilities using IANA timezone names with automatic system detection. It enables LLMs to fetch local or global times and convert specific timestamps between different regions.22MIT