time mcp server

With a custom timezone:

{
  "mcpServers": {
    "time": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e", "LOCAL_TIMEZONE=America/New_York",
        "registry.ghost-prod.alphabravo.io/ghost-base/time-mcp"
      ]
    }
  }
}

Environment Variables

Optional environment variables:

• LOCAL_TIMEZONE (optional): Set the local timezone (default: UTC)

Running the Server

Using UTC (default):

docker run --rm -i \
  registry.ghost-prod.alphabravo.io/ghost-base/time-mcp

With a specific timezone:

docker run --rm -i \
  -e LOCAL_TIMEZONE=America/Los_Angeles \
  registry.ghost-prod.alphabravo.io/ghost-base/time-mcp

Available Tools

The Time MCP Server provides the following capabilities:

Current Time:

• Get current time in UTC
• Get current time in specified timezone
• Get current timestamp

Timezone Conversion:

• Convert time between timezones
• List available timezones
• Get timezone information and offsets

Time Calculations:

• Calculate time differences
• Add or subtract time intervals
• Parse and format time strings

Date Operations:

• Get current date
• Calculate date differences
• Format dates in various formats

Common Timezone Identifiers

Americas:

• America/New_York - Eastern Time
• America/Chicago - Central Time
• America/Denver - Mountain Time
• America/Los_Angeles - Pacific Time
• America/Toronto - Eastern Time (Canada)

Europe:

• Europe/London - GMT/BST
• Europe/Paris - CET/CEST
• Europe/Berlin - CET/CEST
• Europe/Moscow - MSK

Asia:

• Asia/Tokyo - JST
• Asia/Shanghai - CST
• Asia/Dubai - GST
• Asia/Singapore - SGT
• Asia/Kolkata - IST

Pacific:

• Pacific/Auckland - NZST/NZDT
• Australia/Sydney - AEST/AEDT

Example Use Cases

Current Time Query

Query: "What time is it now?"
Server returns current time in configured timezone

Timezone Conversion

Query: "What time is 3 PM Pacific Time in London?"
Server converts and returns the equivalent time

Meeting Scheduling

Query: "When is 9 AM Tokyo time in New York?"
Server performs timezone conversion for scheduling

Time Difference Calculation

Query: "How many hours between 2 PM today and 9 AM tomorrow?"
Server calculates and returns the time difference

Date Formatting

Query: "Format today's date in ISO 8601 format"
Server returns properly formatted date string

Time Arithmetic

Query: "What's the date 30 days from now?"
Server calculates and returns the future date

Timezone Best Practices

1. Use IANA Timezone Names: Use full IANA timezone identifiers (e.g., America/New_York)
2. Avoid Abbreviations: Don't use abbreviations like PST, EST (they're ambiguous)
3. Handle DST: IANA identifiers automatically handle daylight saving time
4. UTC for Storage: Store timestamps in UTC, convert for display
5. Explicit Timezone: Always specify timezone explicitly when needed

Working with Timestamps

Unix Timestamps:

Query: "Convert Unix timestamp 1672531200 to datetime"
Server converts to human-readable format

ISO 8601:

Query: "Parse 2024-03-15T14:30:00Z"
Server parses and provides structured datetime information

Time Format Examples

Common Formats:

• ISO 8601: 2024-03-15T14:30:00Z
• RFC 3339: 2024-03-15T14:30:00+00:00
• Unix Timestamp: 1710511800
• Human Readable: March 15, 2024 2:30 PM

Use Cases by Domain

Project Management:

Calculate deadlines across timezones
Schedule international meetings
Track time-sensitive milestones

International Coordination:

Convert business hours across regions
Schedule global team calls
Coordinate release times

Time-Based Automation:

Schedule jobs at specific times
Calculate recurring intervals
Handle time-based triggers

Logging and Analytics:

Convert log timestamps to local time
Analyze time-series data
Generate time-based reports

Performance Tips

• Cache timezone data for frequently used timezones
• Use UTC internally, convert only for display
• Leverage batch operations for multiple conversions
• Pre-calculate common timezone offsets

Common Use Patterns

Global Team Coordination:

Query: "Team members in Tokyo (9 AM), London (1 AM), and New York (8 PM) -
       what's a good meeting time?"
Server analyzes overlapping business hours

Release Scheduling:

Query: "If we release at midnight UTC, what time is that for users in
       California, London, and Sydney?"
Server provides all timezone conversions

SLA Monitoring:

Query: "Calculate time remaining until SLA breach in 4 hours from now"
Server computes deadline and provides countdown

Additional Resources

• Time MCP Server Documentation
• IANA Time Zone Database
• ISO 8601 Standard
• Model Context Protocol

Non-hardened images vs Ghost hardened images

Key differences

Why no shell or package manager?

Ghost hardened images prioritize security through minimalism:

• Reduced attack surface: Fewer binaries mean fewer potential vulnerabilities
• Immutable infrastructure: Runtime containers shouldn't be modified after deployment
• Compliance ready: Meets strict security requirements for regulated environments

The hardened images intended for runtime don't contain a shell nor any tools for debugging. Common debugging methods for applications built with Ghost hardened images include:

• Docker Debug to attach to containers
• Docker's Image Mount feature to mount debugging tools
• Ecosystem-specific debugging approaches

Docker Debug provides a shell, common debugging tools, and lets you install other tools in an ephemeral, writable layer that only exists during the debugging session.

For example, you can use Docker Debug:

docker debug <container-name>

or mount debugging tools with the Image Mount feature:

docker run --rm -it --pid container:my-time-mcp \
  --mount=type=image,source=registry.ghost-prod.alphabravo.io/ghost-base/busybox,destination=/dbg,ro \
  registry.ghost-prod.alphabravo.io/ghost-base/time-mcp:<tag> /dbg/bin/sh

Image variants

Ghost hardened images come in different variants depending on their intended use.

Runtime variants are designed to run your application in production. These images are intended to be used either directly or as the FROM image in the final stage of a multi-stage build. These images typically:

• Run as the nonroot user
• Do not include a shell or a package manager
• Contain only the minimal set of libraries needed to run the app

Build-time variants typically include dev in the variant name and are intended for use in the first stage of a multi-stage Dockerfile. These images typically:

• Run as the root user
• Include a shell and package manager
• Are used to build or compile applications

FIPS variants

FIPS variants include fips in the variant name and tag. They come in both runtime and build-time variants. These variants use cryptographic modules that have been validated under FIPS 140, a U.S. government standard for secure cryptographic operations.

For example, usage of MD5 fails in FIPS variants. To verify FIPS compliance, check the cryptographic module version in use by your Argo CD instance.

Migrate to a Ghost hardened image

To migrate your application to a Ghost hardened image, you must update your Dockerfile. At minimum, you must update the base image in your existing Dockerfile to a Ghost hardened image. This and a few other common changes are listed in the following table of migration notes:

The following steps outline the general migration process.

1. Find hardened images for your app.

   A hardened image may have several variants. Inspect the image tags and find the image variant that meets your needs.

2. Update the base image in your Dockerfile.

   Update the base image in your application's Dockerfile to the hardened image you found in the previous step. For framework images, this is typically going to be an image tagged as dev because it has the tools needed to install packages and dependencies.

3. For multi-stage Dockerfiles, update the runtime image in your Dockerfile.

   To ensure that your final image is as minimal as possible, you should use a multi-stage build. All stages in your Dockerfile should use a hardened image. While intermediary stages will typically use images tagged as dev, your final runtime stage should use a non-dev image variant.

4. Install additional packages

   Ghost hardened images contain minimal packages in order to reduce the potential attack surface. You may need to install additional packages in your Dockerfile. Inspect the image variants to identify which packages are already installed.

   Only images tagged as dev typically have package managers. You should use a multi-stage Dockerfile to install the packages. Install the packages in the build stage that uses a dev image. Then, if needed, copy any necessary artifacts to the runtime stage that uses a non-dev image.

   For Alpine-based images, you can use apk to install packages. For Debian-based images, you can use apt-get to install packages.

Troubleshoot migration

General debugging

The hardened images intended for runtime don't contain a shell nor any tools for debugging. The recommended method for debugging applications built with Ghost hardened images is to use Docker Debug to attach to these containers. Docker Debug provides a shell, common debugging tools, and lets you install other tools in an ephemeral, writable layer that only exists during the debugging session.

Permissions

By default image variants intended for runtime, run as the nonroot user. Ensure that necessary files and directories are accessible to the nonroot user. You may need to copy files to different directories or change permissions so your application running as the nonroot user can access them.

Privileged ports

Non-dev hardened images run as a nonroot user by default. As a result, applications in these images can't bind to privileged ports (below 1024) when running in Kubernetes or in Docker Engine versions older than 20.10.

No shell

By default, image variants intended for runtime don't contain a shell. Use dev images in build stages to run shell commands and then copy any necessary artifacts into the runtime stage. In addition, use Docker Debug to debug containers with no shell.

Entry point

Ghost hardened images may have different entry points than images such as Docker Official Images. Use docker inspect to inspect entry points for Ghost hardened images and update your Dockerfile if necessary.