用于时间、时区和持续时间工具的 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/mcp基于 somamcp 构建，后者为两种运行时提供 MCP 管道、遥测以及健康/自省端点。时间逻辑是纯粹且函数式的，使用 functype。
工具 | 用途 |
| 当前时间，以 epoch、UTC ISO-8601 以及任意 IANA 时区的挂钟时间表示 |
| 在目标时区中渲染 ISO-8601 时间戳 |
| 添加或减去 ISO-8601 持续时间，支持感知日历的月份运算 |
| 两个时间戳之间的经过时间，以整数单位表示，并附有可读摘要 |
somamcp 还注册了一个 info 工具以及 /health、/health/detail、/info 和 /dashboard 端点。
月份运算采用钳制而非溢出。 对 2026-01-31 使用 P1M 调用 add_duration 返回 2026-02-28，而不是 2026-03-03。将“一个月”加到长月的末尾会落在短月的末尾。
偏移量按瞬间解析，而非按区解析。 America/New_York 在八月报告 -04:00，在一月报告 -05:00。夏令时来自运行时的 tz 数据库，因此这里没有会过时的偏移量表。
错误带有提示。 未知时区会返回错误值以及预期格式，因此调用代理可以自行纠正，而不是再次猜测。
Related MCP server: mcp-datetimeday
Stdio 是默认模式，也是本地客户端所期望的模式。不托管任何内容，不监听端口——你的客户端启动该进程并通过 stdin/stdout 与之通信。
claude mcp add temporal -- npx -y temporal-mcp-server添加到 claude_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.js只有 JSON-RPC 会输出到 stdout；日志输出到 stderr，因此管道是安全的。
对于支持流式 HTTP 而非 stdio 的客户端：
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 之前失败。
部署通过 Cloudflare Workers Builds 而非 GitHub Actions 进行，因此 GitHub 中完全不存储 Cloudflare API 令牌——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。若要要求 Bearer 令牌：
wrangler secret put MCP_AUTH_TOKEN设置 MCP_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/edgesomamcp 的根桶文件重新导出了导入 node:fs 的辅助函数。从 Worker 导入它会将 Node 内置模块拖入包中。因此 src/worker.ts 导入 somamcp/edge，并且如果 node: 导入、裸 Node 内置模块或根 somamcp 说明符到达 worker 包，pnpm check:worker 会使构建失败。
该检查从 dist/worker.js 遍历实际的导入图，而不是匹配文件名——打包器会将与 Node 入口共享的代码提升到带有生成名称的块中，而文件名通配符会跳过最可能携带泄漏的那个文件。
nodejs_compat 被有意地未在 wrangler.jsonc 中启用。如果将来出现 Node 内置模块，构建应该大声失败，而不是被静默填充。
wrangler.jsonc 中的 alias 块xsschema（通过 fastmcp 传递）会通过动态导入探测它支持的每个 schema 库——valibot、effect、sury。我们只使用 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