시간, 시간대, 기간 도구를 위한 MCP 서버입니다.
stdio를 통한 로컬 실행(Claude Desktop, Claude Code, 모든 로컬 MCP 클라이언트), HTTP를 통한 로컬 실행, 또는 호스팅 인스턴스 사용 — 동일한 도구, 동일한 코드, 세 가지 실행 방법.
공개 인스턴스는 Cloudflare Workers에서 https://time.somamcp.com/mcp 주소로 실행됩니다:
claude mcp add --transport http temporal https://time.somamcp.com/mcpsomamcp 기반으로, 두 런타임 모두에 MCP 배관, 원격 측정, 상태/인트로스펙션 엔드포인트를 제공합니다. 시간 로직은 순수 함수형이며, functype을 사용합니다.
도구 | 목적 |
| 임의의 IANA 시간대에서 epoch, UTC ISO-8601, 벽시계(wall-clock) 기준 현재 시간 |
| ISO-8601 타임스탬프를 대상 시간대 기준으로 표시 |
| ISO-8601 기간을 더하거나 빼며, 달력 인식 월 계산 지원 |
| 두 타임스탬프 사이의 경과 시간을 정수 단위와 읽기 쉬운 요약으로 제공 |
somamcp는 또한 info 도구와 /health, /health/detail, /info, /dashboard 엔드포인트를 등록합니다.
월 계산은 오버플로 대신 클램프됩니다. 2026-01-31에 P1M을 add_duration하면 2026-03-03이 아니라 2026-02-28을 반환합니다. 긴 달의 끝에 "한 달"을 더하면 짧은 달의 끝에 도달합니다.
오프셋은 시간대가 아닌 각 시점별로 해석됩니다. America/New_York는 8월에 -04:00, 1월에 -05:00으로 보고됩니다. DST는 런타임의 tz 데이터베이스에서 오므로, 여기에는 낡아서 틀어질 오프셋 테이블이 없습니다.
오류에는 힌트가 포함됩니다. 알 수 없는 시간대는 잘못된 값 및 예상 형식을 반환하므로, 호출 에이전트가 다시 추측하는 대신 스스로 수정할 수 있습니다.
Related MCP server: mcp-datetimeday
Stdio가 기본값이며 로컬 클라이언트가 기대하는 모드입니다. 호스팅되는 것은 없고 포트를 수신하지 않습니다 — 클라이언트가 프로세스를 시작하고 stdin/stdout으로 통신합니다.
claude mcp add temporal -- npx -y temporal-mcp-serverclaude_desktop_config.json에 추가하십시오:
{
"mcpServers": {
"temporal": {
"command": "npx",
"args": ["-y", "temporal-mcp-server"]
}
}
}macOS에서 이 파일은 ~/Library/Application Support/Claude/claude_desktop_config.json에 있으며, Windows에서는 %APPDATA%\Claude\claude_desktop_config.json에 있습니다. 편집 후 Claude Desktop을 다시 시작하십시오.
npm을 거치지 않으려면:
pnpm install
pnpm build
pnpm start # stdio그런 다음 클라이언트가 빌드된 엔트리 포인트를 가리키게 하십시오:
claude mcp add temporal -- node /absolute/path/to/temporal-mcp-server/dist/node.js{
"mcpServers": {
"temporal": {
"command": "node",
"args": ["/absolute/path/to/temporal-mcp-server/dist/node.js"]
}
}
}패키지는 또한 temporal-mcp-server 바이너리를 설치하므로, 전역 설치(npm i -g temporal-mcp-server) 후에는 해당 이름을 명령으로 직접 사용할 수 있습니다.
서버는 stdout에서 JSON-RPC로 통신하므로 직접 수동으로 구동할 수 있습니다:
printf '%s\n%s\n%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"smoke","version":"1.0.0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_current_time","arguments":{"timezone":"Asia/Tokyo"}}}' \
| node dist/node.jsstdout에는 JSON-RPC만 출력되고 로그는 stderr로 가므로 파이핑은 안전합니다.
stdio 대신 스트리밍 HTTP를 사용하는 클라이언트의 경우:
pnpm start:http # http://localhost:3333/mcp — override the port with PORT동일한 서버와 동일한 도구이며, 전송 방식만 다릅니다.
pnpm cf:dev # local workerd runtime
pnpm cf:deploy # build + edge-safety check + deploycf:deploy는 먼저 pnpm build를 실행하며, 여기에는 check:worker가 포함됩니다 — 따라서 Node 내장 모듈을 포함한 번들은 Cloudflare에 도달하기 전에 실패합니다.
배포는 GitHub Actions가 아닌 Cloudflare Workers Builds를 통해 실행되므로, Cloudflare API 토큰이 GitHub에 전혀 저장되지 않습니다 — Cloudflare는 자체 GitHub App을 통해 리포지토리에 연결됩니다.
대시보드에서 한 번 설정하십시오 (Workers & Pages → temporal-mcp-server → Settings → Build):
필드 | 값 |
배포 명령 |
|
빌드 명령 | (비워 둘 것 — |
루트 디렉터리 | (리포지토리 루트) |
배포 명령을 패키지 스크립트로 지정하면 게이팅 로직이 버전 관리에 유지되고, 대시보드에는 안정적인 한 줄만 유지됩니다. 대시보드의 Worker 이름은 wrangler.jsonc의 name(temporal-mcp-server)과 일치해야 하며, 그렇지 않으면 빌드가 실패합니다.
빌드 이미지에는 pnpm이 포함되어 있으며 .nvmrc를 따릅니다(우리 것은 Node 24를 고정). 프로덕션이 아닌 브랜치는 기본적으로 npx wrangler versions upload를 사용하므로, 브랜치 푸시는 라이브 배포에 영향을 주지 않고 미리보기 버전을 생성합니다.
MCP 엔드포인트는 /mcp에 있습니다. 베어러 토큰을 요구하려면:
wrangler secret put MCP_AUTH_TOKENMCP_AUTH_TOKEN이 설정되면 /mcp에 대한 인증되지 않은 호출은 401을 받습니다. 설정하지 않으면 엔드포인트는 공개됩니다 — 시계에는 적합하지만 그 외에는 적합하지 않습니다.
선택적 vars: GIT_COMMIT과 ENVIRONMENT는 info 도구와 /info에서 노출됩니다.
공개 인스턴스는 사용자 정의 도메인에서 제공됩니다:
claude mcp add --transport http temporal https://time.somamcp.com/mcp토큰이 설정된 경우 헤더로 전달하십시오:
claude mcp add --transport http temporal https://time.somamcp.com/mcp \
--header "Authorization: Bearer $MCP_AUTH_TOKEN"상태 확인: https://time.somamcp.com/health.
pnpm cf:dev는 http://localhost:8787/mcp에서 동일한 기능을 제공하므로, 배포 전에 클라이언트를 로컬 workerd 인스턴스로 지정할 수 있습니다.
somamcp/edge를 import하는 이유somamcp의 루트 배럴(barrel)은 node:fs를 import하는 헬퍼를 다시 내보냅니다. Worker에서 이를 import하면 Node 내장 모듈이 번들에 포함됩니다. 따라서 src/worker.ts는 somamcp/edge를 import하며, node: import, Node 내장 모듈, 또는 루트 somamcp 지정자가 워커 번들에 도달하면 pnpm check:worker가 빌드를 실패시킵니다.
이 검사는 파일 이름을 매칭하는 대신 dist/worker.js에서 실제 import 그래프를 따라갑니다 — 번들러는 Node 엔트리와 공유되는 코드를 생성된 이름의 청크로 끌어올리므로, 파일 이름 글로브는 누수를 유발할 가능성이 가장 큰 파일을 정확히 건너뛰게 됩니다.
nodejs_compat는 wrangler.jsonc에 의도적으로 활성화되어 있지 않습니다. Node 내장 모듈이 유입되면 조용히 대체되지 않고 빌드가 명확하게 실패해야 합니다.
alias 블록xsschema(fastmcp를 통한 전이적 의존성)는 지원하는 모든 스키마 라이브러리 — valibot, effect, sury — 를 동적 import로 탐색합니다. 우리는 zod만 사용하므로 해당 분기는 실행되지 않지만, esbuild는 여전히 지정자를 해석해야 합니다. 이들은 사용하지 않는 세 개의 라이브러리를 설치하는 대신 빈 모듈로 별칭 지정됩니다.
src/
clock.ts pure time logic — Either<TemporalError, T>, no I/O, no globals
tools.ts MCP tool registration; takes a server, creates none
index.ts library surface (runtime-agnostic)
node.ts entry: somamcp -> stdio + httpStream
worker.ts entry: somamcp/edge -> export default { fetch }registerTemporalTools(server)는 서버를 직접 만들지 않고 받아들이므로 두 엔트리 포인트가 동일한 도구를 등록합니다. clock.ts, tools.ts, index.ts의 어느 것도 process, 파일시스템 또는 Node 내장 모듈에 접근하지 않습니다.
실패는 값입니다. clock.ts의 모든 실패 가능 함수는 Either<TemporalError, T>를 반환하며, 도구 계층은 Left를 MCP 오류 결과로 접습니다. 스택 해제에 의존하는 것이 없으므로, 동일한 로직이 두 런타임에서 수정 없이 실행될 수 있습니다.
pnpm validate # format + lint + typecheck + test + build
pnpm test # 34 tests
pnpm check:worker # verify the worker bundle is edge-safetest/worker.spec.ts는 MCP 와이어 프로토콜을 통해 실제 Request 객체로 Worker의 fetch 핸들러를 구동하므로, 통합 문제는 배포 후가 아니라 CI에서 드러납니다.
MIT
Add an ISO-8601 duration to a timestamp, in a timezone. Date units (Y/M/D) are calendar-aware: P1D across a DST boundary keeps the same wall-clock time the next day, and P1M on Jan 31 clamps to the end of February. Time units (H/M/S) are exact elapsed time, so PT24H really is 24 hours. Prefix the duration with '-' to subtract.
| Name | Required | Description | Default |
|---|---|---|---|
| duration | Yes | ISO-8601 duration, e.g. 'P1D', 'PT30M', 'P1Y2M3DT4H5M6S', or '-P1W'. | |
| timezone | No | IANA timezone governing the arithmetic — calendar units are applied to this zone's wall clock, and a timestamp with no 'Z' or offset is read as wall-clock time here. Defaults to UTC. | |
| isoTimestamp | Yes | ISO-8601 timestamp to shift. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It explains DST boundary behavior, month-end clamping, exact elapsed time for time units, and the '-' subtraction prefix. This is exemplary transparency for a pure arithmetic tool.
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?
The description is three sentences, front-loaded with the core action, then efficiently details edge-case behavior. Every sentence adds value; there is no filler or repetition of schema content.
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?
For a moderately complex tool with no annotations and no output schema, the description covers the important behavioral nuances (DST, month-end, subtraction) thoroughly. It does not mention return value format or error cases, but those are relatively predictable for this operation, so the gap is minor.
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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining how duration units behave (calendar-aware vs exact elapsed time) and how timezone affects wall-clock arithmetic, which enriches the parameter meanings.
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?
The description opens with a specific verb and resource: 'Add an ISO-8601 duration to a timestamp, in a timezone.' It clearly distinguishes this arithmetic tool from siblings like time_between (difference), convert_timezone (zone conversion), and get_current_time (current time).
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?
The description gives clear context for when the tool is appropriate—duration arithmetic with calendar-aware behavior—but it does not explicitly name alternatives or state when not to use it. Sibling tool names imply the differentiation, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an ISO-8601 timestamp as wall-clock time in a target timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| isoTimestamp | Yes | ISO-8601 timestamp to convert, e.g. '2026-08-17T14:30:00Z'. | |
| sourceTimezone | No | IANA timezone used to interpret `isoTimestamp` when it carries no 'Z' or offset. Ignored otherwise. Defaults to UTC. | |
| targetTimezone | Yes | IANA timezone identifier to render in. |
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 does not mention how source timezones are handled, DST behavior, return format, or error cases, leaving important operational details implicit.
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?
The description is a single, concise sentence that front-loads the core action. Every word earns its place, with no redundancy or filler.
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?
For a simple 3-parameter tool with full schema coverage, the description is minimally adequate. However, without annotations or an output schema, it leaves the return format and the optional sourceTimezone edge cases unstated, which would help the agent use the tool more confidently.
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 description coverage is 100%, so the parameters are already well-documented. The description adds no additional parameter-specific meaning, so the baseline of 3 applies.
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?
The description uses a specific verb ('Render') and clearly names both the input (ISO-8601 timestamp) and the desired outcome (wall-clock time in a target timezone). This distinguishes it from sibling tools like get_current_time and time_between.
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?
The description provides no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites. It simply describes the operation without contextualizing it against siblings such as add_duration or time_between.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current time as an epoch, a UTC ISO-8601 timestamp, and the wall-clock time in a given timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | IANA timezone identifier, e.g. 'America/New_York'. Defaults to UTC. |
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 time in three formats and accepts an optional timezone, but it does not explicitly state that the operation is read-only, non-destructive, or side-effect-free. For a simple read tool, this is adequate but not exhaustive.
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?
The description is a single sentence (18 words) that is front-loaded with the verb 'Return'. Every word contributes value, with no redundancy or filler.
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?
Given the tool's simplicity (one optional parameter, no output schema), the description fully explains what the tool returns (epoch, ISO-8601 timestamp, wall-clock time in timezone). No additional information is necessary for correct invocation.
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 description coverage is 100% (the only parameter 'timezone' already has a description including 'Defaults to UTC'). The tool description adds no new information beyond the schema, so the baseline score of 3 applies.
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?
The description clearly states the verb 'Return' and the resource 'current time' with specific outputs (epoch, ISO-8601 timestamp, wall-clock time in timezone). It distinguishes itself from sibling tools like convert_timezone and time_between by focusing on the current moment rather than conversions or calculations.
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 is given on when to use this tool versus alternatives (e.g., convert_timezone, time_between). There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns identity and build information for this server (name, version, build commit, runtime, capability counts)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description's disclosure of a read operation is consistent. It adds value by specifying the exact return content (name, version, build commit, runtime, capability counts), which is not captured in the annotations. No behavioral contradictions or hidden effects.
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?
The description is a single sentence that is front-loaded with the purpose ('Returns identity and build information for this server') and immediately lists the specific fields. Every word earns its place; there is no redundancy or fluff.
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?
Given the tool has no parameters, no output schema, and is read-only, the description fully covers what the agent needs to know: what it returns (identity and build info with listed fields). The context of sibling tools is clear, and no additional information is needed for correct invocation.
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 tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to explain parameters since there are none. It adds no additional parameter information but none is required.
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?
The description explicitly states the tool returns 'identity and build information for this server' and lists the specific fields (name, version, build commit, runtime, capability counts). This clearly distinguishes it from the sibling tools, which are all time-related operations.
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?
The description does not explicitly state when to use this tool versus alternatives. However, the sibling tools are all time-focused (get_current_time, convert_timezone, etc.), so the context implies this is the tool for server info. No explicit guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact elapsed time between two ISO-8601 timestamps, broken into days/hours/minutes/seconds plus a human-readable summary. All components share one sign, so they sum correctly; direction is 'past', 'future', or 'same'.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End of the interval, as an ISO-8601 timestamp. | |
| from | Yes | Start of the interval, as an ISO-8601 timestamp. | |
| timezone | No | IANA timezone used to interpret timestamps that carry no 'Z' or offset. Defaults to UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output breakdown (days/hours/minutes/seconds), a human-readable summary, consistent sign behavior, and a direction field. It does not cover edge cases like invalid timestamps or DST, but the disclosed details give good 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both information-dense. The first delivers the core purpose, the second highlights the sign and direction semantics. No redundant or filler content.
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?
Even without an output schema, the description covers the main return components and behaviors. The tool is relatively simple, and the described details are sufficient for an agent to understand what will come back. Minor gaps like exact return type or error handling prevent a perfect score.
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 description coverage is 100%, so the schema fully documents all three parameters. The description adds no extra parameter-level meaning beyond restating the concept of the interval; baseline 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?
The description clearly states the tool computes 'exact elapsed time between two ISO-8601 timestamps', which is a specific verb-resource combination. It also distinguishes from siblings like add_duration or convert_timezone by focusing purely on time intervals.
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?
The purpose is self-evident: when an agent needs elapsed time between two timestamps, this is the tool. However, it does not explicitly call out when not to use it or mention alternatives, so it misses the bar for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.2add_duration1 field changedInput schema / properties / timezone / descriptionPrevious value: -"IANA timezone identifier, e.g. 'America/New_York'. Defaults to UTC."New value: +"IANA timezone governing the arithmetic — calendar units are applied to this zone's wall clock, and a timestamp with no 'Z' or offset is read as wall-clock time here. Defaults to UTC."convert_timezone1 field changedInput schema / properties / sourceTimezoneAdded value: +{
+ "description": "IANA timezone used to interpret `isoTimestamp` when it carries no 'Z' or offset. Ignored otherwise. Defaults to UTC.",
+ "type": "string"
+}time_between1 field changedInput schema / properties / timezoneAdded value: +{
+ "description": "IANA timezone used to interpret timestamps that carry no 'Z' or offset. Defaults to UTC.",
+ "type": "string"
+}v0.1.0add_durationconvert_timezoneget_current_timeinfotime_betweenScored across 5 tools
Each tool has a clearly distinct purpose: current time, timezone conversion, duration arithmetic, elapsed time, and server info. There is no meaningful overlap or ambiguity between them.
Most tools follow a consistent snake_case verb_noun pattern (add_duration, get_current_time, convert_timezone). The exception is 'info', which is a noun rather than a verb phrase, but this is a minor deviation.
Five tools is well-scoped for a focused temporal/time utility server. Each tool provides a distinct, non-redundant capability, and none feel unnecessary.
The core temporal workflows are covered: obtaining current time, converting timezones, adding durations, and measuring elapsed time. Missing advanced operations like listing timezones or extracting date components are minor gaps that agents can work around.
Timezone MCP — wraps timeapi.io (free, no auth)
timesheet.io MCP server - manage timers, projects, tasks and reports