Skip to main content
Glama
enesjakozh
odgrim

MCP DateTime

by odgrim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

MCP 날짜/시간

에이전트 시스템과 채팅 REPL에 날짜 및 시간대 정보를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버의 TypeScript 구현입니다.

개요

MCP DateTime은 모델 컨텍스트 프로토콜을 구현하여 AI 에이전트와 채팅 인터페이스에 날짜/시간 및 시간대 정보를 제공하는 간단한 서버입니다. AI 시스템은 이를 통해 다음과 같은 작업을 수행할 수 있습니다.

  • 로컬 시스템 시간대의 현재 시간을 가져옵니다.

  • 유효한 시간대의 현재 시간을 가져옵니다.

  • 사용 가능한 모든 시간대를 나열하세요

  • URI 리소스를 통해 시간대 정보에 액세스

Related MCP server: Time Tools MCP Server

설치

npm에서

지엑스피1

출처에서

git clone https://github.com/odgrmi/mcp-datetime.git
cd mcp-datetime
npm install
npm run build

용법

명령줄

MCP DateTime은 두 가지 모드로 실행할 수 있습니다.

1. 표준 I/O 모드(기본값)

이 모드는 표준 입출력을 통해 MCP 프로토콜을 지원하는 AI 시스템과 통합하는 데 이상적입니다.

mcp-datetime

2. 서버 전송 이벤트(SSE) 모드

이 모드는 MCP 프로토콜에 대한 SSE 전송을 제공하는 HTTP 서버를 시작합니다.

mcp-datetime --sse

사용자 정의 포트와 URI 접두사를 지정할 수도 있습니다.

mcp-datetime --sse --port=8080 --prefix=/api/datetime

환경 변수

  • PORT : SSE 모드의 포트를 설정합니다(기본값: 3000)

  • URI_PREFIX : SSE 모드에 대한 URI 접두사를 설정합니다(기본값: 없음)

사용 가능한 도구

MCP DateTime은 다음과 같은 도구를 제공합니다.

get-current-time

시스템의 로컬 시간대에 따른 현재 시간을 반환합니다.

get-current-timezone

현재 시스템 시간대를 반환합니다.

get-time-in-timezone

지정된 시간대의 현재 시간을 반환합니다.

매개변수:

  • timezone : 현재 시간을 가져올 시간대(예: "America/New_York")

list-timezones

사용 가능한 모든 시간대 목록을 반환합니다.

리소스 URI

MCP DateTime은 리소스 URI를 통해 시간대 정보에 대한 액세스도 제공합니다.

datetime://{timezone}

지정된 시간대의 현재 시간을 반환합니다.

예: datetime://America/New_York

datetime://list

사용 가능한 모든 시간대 목록을 반환합니다.

일반 시간대

다음의 일반적인 시간대는 항상 이용 가능합니다.

  • UTC

  • 유럽/런던

  • 유럽/파리

  • 유럽/베를린

  • 미국/뉴욕

  • 미국/시카고

  • 아메리카/덴버

  • 아메리카/로스앤젤레스

  • 아시아/도쿄

  • 아시아/상하이

  • 아시아/콜카타

  • 호주/시드니

  • 태평양/오클랜드

SSE 엔드포인트

SSE 모드에서 실행할 경우 다음 엔드포인트를 사용할 수 있습니다.

  • /sse : SSE 연결 엔드포인트

  • /message : 클라이언트-서버 통신을 위한 메시지 엔드포인트

  • /info : 기본 서버 정보

URI 접두사가 지정되면 모든 엔드포인트에 추가됩니다.

AI 시스템과의 통합

MCP DateTime은 모델 컨텍스트 프로토콜(Model Context Protocol)을 지원하는 AI 시스템과 통합될 수 있습니다. 이를 통해 AI 에이전트는 정확한 시간대 및 날짜/시간 정보에 접근할 수 있습니다.

개발

필수 조건

  • Node.js 14.16 이상

  • 엔피엠

설정

git clone https://github.com/odgrim/mcp-datetime.git
cd mcp-datetime
npm install

짓다

npm run build

개발 모드에서 실행

npm run dev        # Standard I/O mode
npm run dev:sse    # SSE mode

특허

이 프로젝트는 Mozilla Public License 2.0에 따라 라이선스가 부여되었습니다. 자세한 내용은 LICENSE 파일을 참조하세요.

Available Tools

4 tools
get-current-timeB

Get the current time in the configured local timezone

ParametersJSON Schema
NameRequiredDescriptionDefault

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 the tool gets current time but doesn't disclose behavioral traits like whether it's read-only, requires permissions, has rate limits, or what the output format is. This is a significant gap for a tool with zero annotation coverage.

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 that front-loads the purpose with zero waste. Every word earns its place, making it appropriately sized for this simple tool.

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 (0 parameters, no output schema), the description is minimally adequate but lacks details on behavioral aspects like output format or usage context. It doesn't fully compensate for the absence of annotations and output schema, leaving gaps in understanding.

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 parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter information, which is acceptable since there are no parameters to document.

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 action ('Get') and resource ('current time'), specifying it returns time in the configured local timezone. It distinguishes from siblings like get-time-in-timezone by focusing on local time, but doesn't explicitly contrast with get-current-timezone or list-timezones.

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 explicit guidance on when to use this tool versus alternatives like get-current-timezone or get-time-in-timezone. The description implies usage for local time retrieval but lacks context on exclusions or prerequisites.

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

get-current-timezoneB

Get the current system timezone

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, if it requires permissions, how it handles errors, or what format the timezone is returned in (e.g., IANA code, offset).

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, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently conveys the essential information without 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 for a tool that returns data. It doesn't specify what the output looks like (e.g., timezone name, offset, or structured object), which is critical for an agent to use the tool effectively. The simplicity of the tool mitigates this somewhat, but key behavioral context is missing.

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, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema. A baseline of 4 is applied since no parameters exist.

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 action ('Get') and resource ('current system timezone'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-current-time' or 'list-timezones', which prevents a perfect score.

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-time' (which might return time without timezone) or 'list-timezones' (which lists available timezones). The description lacks context about use cases or exclusions.

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

get-time-in-timezoneC

Get the current time in a specific timezone

ParametersJSON Schema
NameRequiredDescriptionDefault
timezoneYesThe timezone to get the current time for

TDQS

C2.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 the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—for example, it doesn't mention error handling for invalid timezones, whether it returns formatted time or raw data, or any rate limits. This leaves significant gaps in understanding the tool's 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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.

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 for a tool that performs a read operation. It doesn't explain what the return value looks like (e.g., formatted string, timestamp), error conditions, or how to handle invalid inputs. This leaves the agent with insufficient context to use the tool effectively.

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%, with the single parameter 'timezone' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as examples of valid timezone formats (e.g., 'America/New_York') or constraints. Baseline 3 is appropriate since 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 clearly states the verb 'get' and the resource 'current time in a specific timezone', making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-current-time' (which might return time without timezone specification) or 'list-timezones' (which lists available timezones rather than getting time for one).

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 its siblings. It doesn't mention alternatives like 'get-current-time' for time without timezone or 'list-timezones' for browsing timezones, nor does it specify prerequisites such as needing a valid timezone identifier.

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

list-timezonesB

List all available timezones

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 action ('List') but doesn't describe return format, pagination, rate limits, or error handling. This is a significant gap for a tool with zero annotation coverage.

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 zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.

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 the return value looks like (e.g., list format, timezone identifiers), which is critical for a tool that lists data. This gap reduces usability for an AI agent.

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 appropriately doesn't mention parameters, earning a high baseline score for not adding unnecessary information.

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 ('List') and resource ('all available timezones'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-current-timezone' or 'get-time-in-timezone', which prevents a perfect score.

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-timezone' or 'get-time-in-timezone'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from tool names 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. 4 tool updatesv1.0.0
    • Addedget-current-time
    • Addedget-current-timezone
    • Addedget-time-in-timezone
    • Addedlist-timezones
Deploy Server
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored across 4 tools

Disambiguation5/5

Every tool has a clearly distinct purpose with no ambiguity: get-current-time retrieves local time, get-current-timezone returns the system timezone, get-time-in-timezone fetches time for a specified zone, and list-timezones enumerates available zones. The descriptions make it impossible to confuse these tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with hyphens (e.g., get-current-time, list-timezones). This predictable naming scheme enhances readability and agent usability without any deviations.

Tool Count5/5

With 4 tools, the server is well-scoped for handling date/time operations. Each tool earns its place by covering core functionalities: retrieving time, managing timezones, and listing options, making the count appropriate for the domain.

Completeness5/5

The tool surface provides complete coverage for basic date/time operations: it supports getting current time (locally and in specific zones), accessing timezone information, and listing all available zones. There are no obvious gaps for this focused purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Time Server

    jharkins
    A
    license
    Not graded
    quality
    D
    maintenance
    A TypeScript server that provides time-related tools through the Model Context Protocol, allowing users to get current time in various timezones and convert times between different IANA timezones.
    MIT

  • Time MCP Server

    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.
    2
    MIT

  • Time

    TheoBrigitte
    A
    license
    Not graded
    quality
    D
    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
    543 npm
    25
    MIT

Appeared in Searches