時間、タイムゾーン、期間のツール向けのMCPサーバー。
stdio経由のローカル実行（Claude Desktop、Claude Code、あらゆるローカルMCPクライアント）、HTTP経由のローカル実行、またはホステッドインスタンスの利用—同じツール、同じコード、3つの実行方法です。
公開インスタンスはCloudflare Workers上で https://time.somamcp.com/mcp として動作しています:
claude mcp add --transport http temporal https://time.somamcp.com/mcpsomamcp を基盤としており、MCPの配管、テレメトリー、両ランタイム向けのヘルス/イントロスペクションエンドポイントを提供します。時間ロジックは純粋で関数型であり、functype を使用しています。
ツール | 目的 |
| 現在時刻をエポック、UTC ISO-8601、任意のIANAタイムゾーンの現地時刻として返します |
| ISO-8601タイムスタンプをターゲットタイムゾーンで表示します |
| ISO-8601期間を加算・減算します。カレンダーを考慮した月の算術演算を行います |
| 2つのタイムスタンプ間の経過時間を、整数単位と読みやすい要約で返します |
somamcp はまた、info ツールと /health、/health/detail、/info、/dashboard エンドポイントを登録します。
月の算術演算はオーバーフローせずクランプされます。 2026-01-31 に対して P1M で add_duration を実行すると、2026-03-03 ではなく 2026-02-28 を返します。長い月の月末に「1ヶ月」を加えると、短い月の月末になります。
オフセットはゾーンごとではなく各瞬間ごとに解決されます。 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）:
フィールド | 値 |
デプロイコマンド |
|
ビルドコマンド | (空のまま — |
ルートディレクトリ | (リポジトリルート) |
デプロイコマンドをパッケージスクリプトに指定することで、ゲーティングロジックをバージョン管理下に置けます。ダッシュボードには安定した1行だけを保持します。ダッシュボードの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 をインポートする理由somamcp のルートバレルは node:fs をインポートするヘルパーを再エクスポートします。Workerからインポートすると、Node組み込みがバンドルに取り込まれます。そのため src/worker.ts は somamcp/edge をインポートし、pnpm check:worker は node: インポート、ベアのNode組み込み、またはルートの somamcp 指定子がworkerバンドルに到達した場合にビルドを失敗させます。
このチェックは、ファイル名の一致ではなく dist/worker.js から実際のインポートグラフを辿ります。バンドラーはNodeエントリと共有するコードを生成された名前のチャンクに巻き上げるため、ファイル名グロブはリークを運ぶ可能性が最も高いファイルを正確にスキップしてしまいます。
nodejs_compat は意図的に wrangler.jsonc で有効化されていません。Node組み込みが万一届いた場合、静かにシムされるのではなく、ビルドは明示的に失敗すべきです。
alias ブロックxsschema（fastmcpを介して推移的に）は、動的インポートを通じてサポートするすべてのスキーマライブラリ（valibot、effect、sury）をプローブします。我々はzodのみを使用するため、これらのブランチは実行されませんが、esbuildは依然として指定子を解決する必要があります。これらは未使用の3つのライブラリをインストールする代わりに、空のモジュールにエイリアスされます。
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 は、実際の Request オブジェクトをMCPワイヤプロトコル経由で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