What can you do with this server?

The server provides time, timezone, and duration MCP tools that can be run locally over stdio/HTTP or used via a hosted Cloudflare Worker endpoint. * get_current_time — returns the current time as epoch, UTC ISO-8601, and wall-clock time in any IANA timezone. * convert_timezone — renders an ISO-8601 timestamp in a target timezone, with optional source timezone for naive timestamps. * add_duration — adds or subtracts ISO-8601 durations with calendar-aware month/day arithmetic (e.g., DST-safe, month-end clamping) and exact time-unit arithmetic. * time_between — computes elapsed time between two timestamps in whole days/hours/minutes/seconds, with a readable summary and past/future/same direction. * info — returns server identity, build commit, runtime, and capability counts. * Deployment flexibility — run the same tools via stdio for local MCP clients, as a local HTTP server, or connect to the hosted instance at https://time.somamcp.com/mcp. * Strict, predictable behavior — timestamp parsing is ISO-8601 only, timezone arithmetic is applied per instant, and errors include hints to help agents self-correct.

How do I use temporal-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@temporal-mcp-server what time is it in Tokyo?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

temporal-mcp-server

by jordanburke

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

temporal-mcp-server

npm version

MCP server for time, timezone, and duration tools.

Run it locally over stdio (Claude Desktop, Claude Code, any local MCP client), locally over HTTP, or use the hosted instance — same tools, same code, three ways to run it.

A public instance runs on Cloudflare Workers at https://time.somamcp.com/mcp:

claude mcp add --transport http temporal https://time.somamcp.com/mcp

Built on somamcp (README · npm), which supplies the MCP plumbing, telemetry, and health/introspection endpoints for both runtimes. Time logic is pure and functional, using functype.

Tools

Tool	Purpose
`get_current_time`	Current time as epoch, UTC ISO-8601, and wall-clock in any IANA timezone
`convert_timezone`	Render an ISO-8601 timestamp in a target timezone
`add_duration`	Add or subtract an ISO-8601 duration, with calendar-aware month arithmetic
`time_between`	Elapsed time between two timestamps, in whole units plus a readable summary

somamcp also registers an info tool and /health, /health/detail, /info, and /dashboard endpoints.

Behaviour worth knowing

Date units are calendar units; time units are exact. This is the distinction that makes DST come out right, and it follows ISO-8601 and Temporal:

Across US "fall back"	Result
`2026-11-01T00:00-04:00` + `P1D`	`2026-11-02T00:00` — same wall clock next day (25 real hours)
`2026-11-01T00:00-04:00` + `PT24H`	`2026-11-01T23:00` — exactly 24 hours

Both are correct, and they differ. "Tomorrow" is a calendar idea; "24 hours from now" is a physical one.

timezone governs the arithmetic, not just the rendering. Calendar units are applied to that zone's wall clock, so add_duration in America/New_York behaves the way a person in New York expects.

Month arithmetic clamps rather than overflows. P1M on 2026-01-31 returns 2026-02-28, not 2026-03-03.

Offsets are resolved per instant, not per zone. America/New_York reports -04:00 in August and -05:00 in January. DST comes from the runtime's tz database, so there is no offset table here to go stale.

Naive timestamps are read in the supplied timezone. 2026-11-01T00:00:00 with America/New_York means midnight in New York. It never falls back to the host's zone — that would answer differently on a laptop than on a Worker.

Timestamp parsing is strict. Only ISO-8601 forms are accepted; 17 Aug 2026 is rejected with a hint. new Date() would have taken it and resolved it against whatever zone the process happened to run in.

Elapsed components share one sign. time_between returns all of days/hours/minutes/seconds negative for a backward interval, so summing them is correct, plus a direction of past/future/same.

Errors carry a hint. An unknown timezone returns the bad value and the expected format, so a calling agent can correct itself instead of guessing again.

Related MCP server: mcp-datetimeday

Running as a local MCP server

Stdio is the default and the mode local clients expect. Nothing is hosted, nothing listens on a port — your client launches the process and talks to it over stdin/stdout.

Claude Code

claude mcp add temporal -- npx -y temporal-mcp-server

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "temporal": {
      "command": "npx",
      "args": ["-y", "temporal-mcp-server"]
    }
  }
}

On macOS that file lives at ~/Library/Application Support/Claude/claude_desktop_config.json; on Windows, %APPDATA%\Claude\claude_desktop_config.json. Restart Claude Desktop after editing it.

Running from a clone

If you'd rather not go through npm:

pnpm install
pnpm build
pnpm start          # stdio

Then point your client at the built entry point:

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"]
    }
  }
}

The package also installs a temporal-mcp-server binary, so a global install (npm i -g temporal-mcp-server) lets you use that name directly as the command.

Working in this repo

A checked-in .mcp.json registers the local build as the temporal server, so Claude Code picks up your changes rather than the hosted instance:

{
  "mcpServers": {
    "temporal": {
      "command": "node",
      "args": ["dist/node.js"]
    }
  }
}

Run pnpm build first — it points at dist/, so an unbuilt checkout has nothing to launch.

Verifying it works

The server speaks JSON-RPC on stdout, so you can drive it by hand:

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

Only JSON-RPC goes to stdout; logs go to stderr, so piping is safe.

Running locally over HTTP

For clients that speak streamable HTTP rather than stdio:

pnpm start:http     # http://localhost:3333/mcp — override the port with PORT

This is the same server and the same tools; only the transport differs.

Running remotely on Cloudflare Workers

pnpm cf:dev         # local workerd runtime
pnpm cf:deploy      # build + edge-safety check + deploy

cf:deploy runs pnpm build first, which includes check:worker — so a bundle carrying a Node built-in fails before anything reaches Cloudflare.

Continuous deployment

Deploys run through Cloudflare Workers Builds rather than GitHub Actions, so no Cloudflare API token is stored in GitHub at all — Cloudflare connects to the repo through its own GitHub App.

Set it up once in the dashboard (Workers & Pages → temporal-mcp-server → Settings → Build):

Field	Value
Deploy command	`pnpm cf:deploy`
Build command	(leave empty — `cf:deploy` builds)
Root directory	(repo root)

Pointing the deploy command at a package script keeps the gating logic in version control; the dashboard holds one stable line. The Worker name in the dashboard must match name in wrangler.jsonc (temporal-mcp-server), or the build fails.

The build image ships pnpm and honours .nvmrc (ours pins Node 24). Non-production branches default to npx wrangler versions upload, so branch pushes produce preview versions without touching the live deployment.

The MCP endpoint is at /mcp. To require a bearer token:

wrangler secret put MCP_AUTH_TOKEN

With MCP_AUTH_TOKEN set, unauthenticated calls to /mcp get a 401. Leave it unset and the endpoint is public — reasonable for a clock, not for much else.

Build provenance

scripts/deploy.mjs stamps the deploy with GIT_COMMIT, GIT_BRANCH, and BUILD_DATE, so the info tool and /info report exactly what is running:

curl -s https://time.somamcp.com/info   # protected; also available via the `info` MCP tool

Workers Builds exposes WORKERS_CI_COMMIT_SHA and WORKERS_CI_BRANCH during the build, but build variables are not readable at runtime — they have to be forwarded as Worker vars, which is what the deploy script does. Running pnpm cf:deploy locally falls back to git rev-parse, and a deploy from a dirty tree is stamped <sha>-dirty rather than claiming to be a commit it isn't.

Connecting a client to the deployed worker

The public instance is served from a custom domain:

claude mcp add --transport http temporal https://time.somamcp.com/mcp

With a token set, pass it as a header:

claude mcp add --transport http temporal https://time.somamcp.com/mcp \
  --header "Authorization: Bearer $MCP_AUTH_TOKEN"

Health check: https://time.somamcp.com/health.

pnpm cf:dev serves the same thing on http://localhost:8787/mcp, so you can point a client at a local workerd instance before deploying.

Why the worker imports `somamcp/edge`

somamcp's root barrel re-exports helpers that import node:fs. Importing it from a Worker drags Node built-ins into the bundle. src/worker.ts therefore imports somamcp/edge, and pnpm check:worker fails the build if a node: import, a bare Node built-in, or the root somamcp specifier reaches the worker bundle.

See somamcp's edge runtime docs for the full story, including a feature parity table covering what does and does not work on edge — stdio, sessions, reportProgress, and multi-result resources are all Node-only.

The check walks the actual import graph from dist/worker.js rather than matching filenames — the bundler hoists code shared with the Node entry into a chunk with a generated name, and a filename glob would skip exactly the file most likely to carry a leak.

nodejs_compat is deliberately not enabled in wrangler.jsonc. If a Node built-in ever arrives, the build should fail loudly rather than be silently shimmed.

The `alias` block in wrangler.jsonc

xsschema (transitive, via fastmcp) probes for every schema library it supports — valibot, effect, sury — through dynamic import. We only use zod, so those branches never run, but esbuild still has to resolve the specifiers. They are aliased to an empty module instead of installing three unused libraries.

Architecture

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) takes the server rather than building one, so both entry points register identical tools. Nothing in clock.ts, tools.ts, or index.ts touches process, the filesystem, or any Node built-in.

Failures are values. Every fallible function in clock.ts returns Either<TemporalError, T>; the tool layer folds a Left into an MCP error result. Nothing depends on stack unwinding, which is what lets the same logic run unchanged on both runtimes.

Development

pnpm validate       # format + lint + typecheck + test + build
pnpm test           # 34 tests
pnpm check:worker   # verify the worker bundle is edge-safe

test/worker.spec.ts drives real Request objects through the Worker's fetch handler over the MCP wire protocol, so integration breakage surfaces in CI rather than after a deploy.

License

MIT

Available Tools

5 tools

add_durationA

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.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

A4.4/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

convert_timezoneB

Render an ISO-8601 timestamp as wall-clock time in a target timezone.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

B3.3/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 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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

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, 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.

get_current_timeA

Return the current time as an epoch, a UTC ISO-8601 timestamp, and the wall-clock time in a given timezone.

ParametersJSON Schema

Name	Required	Description	Default
`timezone`	No	IANA timezone identifier, e.g. 'America/New_York'. Defaults to UTC.

TDQS

A3.7/5.0

Behavior3/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 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

infoA

Read-only

Returns identity and build information for this server (name, version, build commit, runtime, capability counts)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

time_betweenA

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'.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.2.2Aug 19, 2026

Changedadd_duration1 field changed

changedInput schema / properties / timezone / description

Previous 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."

Changedconvert_timezone1 field changed

addedInput schema / properties / sourceTimezone

Added value: +{
+  "description": "IANA timezone used to interpret `isoTimestamp` when it carries no 'Z' or offset. Ignored otherwise. Defaults to UTC.",
+  "type": "string"
+}

Changedtime_between1 field changed

addedInput schema / properties / timezone

Added value: +{
+  "description": "IANA timezone used to interpret timestamps that carry no 'Z' or offset. Defaults to UTC.",
+  "type": "string"
+}

5 tool updatesv0.1.0Aug 17, 2026
- First observedadd_duration
- First observedconvert_timezone
- First observedget_current_time
- First observedinfo
- First observedtime_between

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

Five tools is well-scoped for a focused temporal/time utility server. Each tool provides a distinct, non-redundant capability, and none feel unnecessary.

Completeness4/5

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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

timezone A
io.github.pipeworx-io
Timezone MCP — wraps WorldTimeAPI (free, no auth)
Location Services Search
352
mcp-time B
io.github.mcpcentral-io
Time MCP server via HTTP
Search
22
IO Aerospace MCP Server C
org.io-aerospace
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
Aerospace & Astrodynamics Research & Data
214
time-mcp A
io.github.jmavid
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Developer Tools
2

Related MCP Servers

Time
Developer Tools App Automation
TheoBrigitte
A
license
Not graded
quality
C
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
Updated 5 months ago (2026-03-30 10:02 UTC)
184
25
MIT
mcp-datetimeday
Developer Tools
cfdude
A
license
A
quality
D
maintenance
A lightweight MCP server providing comprehensive date, time, and day-of-week information. It supports relative time calculations, timezone conversions, and detailed calendar metadata like week numbers and quarters.
Updated 6 months ago (2026-03-17 15:46 UTC)
5
1
MIT
datetime-mcp
Developer Tools Command Line
joshuaboys
A
license
D
quality
C
maintenance
A lightweight MCP server that provides date and time tools, including the ability to retrieve current timestamps and parse date strings with IANA timezone support. It enables AI models to interact with the host OS clock and perform temporal calculations via stdio transport.
Updated 6 months ago (2026-03-18 16:06 UTC)
3
13
7
MIT
MCP Time Server
Developer Tools
mcpcentral-io
A
license
A
quality
F
maintenance
MCP server providing various date/time functions including current time, timezone conversion, and relative time calculations. Supports both local stdio and remote HTTP access via Cloudflare Workers.
Updated 5 months ago (2026-04-18 13:58 UTC)
6
490
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jordanburke/temporal-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

temporal-mcp-server

Tools

Behaviour worth knowing

Running as a local MCP server

Claude Code

Claude Desktop

Running from a clone

Working in this repo

Verifying it works

Running locally over HTTP

Running remotely on Cloudflare Workers

Continuous deployment

Build provenance

Connecting a client to the deployed worker

Why the worker imports somamcp/edge

The alias block in wrangler.jsonc

Architecture

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Why the worker imports `somamcp/edge`

The `alias` block in wrangler.jsonc