Skip to main content
Glama
jeromeetienne

mcp-now

by jeromeetienne
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp-now

An MCP server that provides tools to get the current date and time. Mainly designed to easily test MCP compatibility.

Tools

get_current_datetime

Returns the current date and time.

Parameter

Type

Required

Description

timezone

string

No

IANA timezone name (e.g. America/New_York). Defaults to local system timezone.

Example output: 03/17/2026, 10:45:00 AM EDT

get_current_date

Returns the current date only (no time).

Parameter

Type

Required

Description

timezone

string

No

IANA timezone name (e.g. America/New_York). Defaults to local system timezone.

Example output: 2026-03-17

Related MCP server: DateTime MCP Server

Install

npm install -g mcp-now

Or run on demand without installing:

npx mcp-now

Usage

Build and run

npm install
npm run build
npm start

Development

npm run dev

Debug with MCP Inspector

npm run inspect

Opens a browser UI at http://localhost:5173 where you can list tools, call them with custom arguments, and inspect raw JSON-RPC messages.

MCP client configuration

Once installed globally (or available via npx), point your MCP client at the mcp-now binary:

{
  "mcpServers": {
    "now": {
      "command": "npx",
      "args": ["mcp-now"]
    }
  }
}

Available Tools

2 tools
get_current_dateA

Get the current date (without time)

ParametersJSON Schema
NameRequiredDescriptionDefault
timezoneNoIANA timezone name (e.g. 'America/New_York'). Defaults to local system timezone.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It only restates the tool's basic behavior and doesn't disclose effects of the timezone parameter or return format, though the tool is simple.

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 with no wasted words, effectively front-loading the key information.

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 simple tool with one optional parameter and no output schema, the description is mostly complete. It could optionally mention the output format, but this is not critical.

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% and the description does not add any information about the timezone parameter beyond what the schema already provides.

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 states the verb 'Get', resource 'current date', and qualifier '(without time)', clearly distinguishing it from the sibling tool 'get_current_datetime'.

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 implies usage for date-only needs versus datetime via the qualifier and sibling name, but does not explicitly state when to use this tool or exclude alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_datetimeC

Get the current date and time

ParametersJSON Schema
NameRequiredDescriptionDefault
timezoneNoIANA timezone name (e.g. 'America/New_York'). Defaults to local system timezone.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description lacks behavioral details such as the return format (string, object), timezone handling, or any side effects. With no annotations, the description carries full burden but only offers a basic statement, missing key traits like output structure.

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, front-loaded, and contains no superfluous words. It is highly concise and directly states the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description should hint at the return value (e.g., format, timezone). It does not, leaving the agent guessing. The tool is simple but still incomplete for practical use.

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?

The schema description covers the 'timezone' parameter (100% coverage), so the description adds no extra value. Baseline 3 is appropriate as the schema already does the job.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'Get' and the resource 'current date and time', clearly indicating the function. However, it does not differentiate from the sibling tool 'get_current_date', which is similar but for date only. The name itself includes 'datetime', but the description misses the opportunity to clarify the distinction.

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 provided on when to use this tool over the sibling 'get_current_date'. There are no context cues or mentions of alternative tools, leaving the agent without decision support for tool selection.

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.

  1. 2 tool updatesv1.0.2
    • First observedget_current_date
    • First observedget_current_datetime
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one returns only the current date, the other returns both date and time. No ambiguity exists between them.

Naming Consistency5/5

Both tools follow a consistent 'get_current_' prefix pattern with specific suffixes 'date' and 'datetime', making them predictable and easy to understand.

Tool Count5/5

For a server focused solely on providing current date/time information, two tools is appropriate and covers the essential use cases without being excessive or insufficient.

Completeness4/5

The server covers the primary need for current date and datetime but lacks timezone support or other date-related operations, which could be considered a minor gap.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP DateTime Server

    gnokit
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides current local datetime information with timezone support. Serves as a minimal blueprint for building simple, single-purpose MCP servers.
    12 npm
    1
    MIT

  • DateTime MCP Server

    ai-mcp-garage
    F
    license
    A
    quality
    Not graded
    maintenance
    Provides timezone-aware date and time information with configurable time formats and timezone support. Enables users to get current date and time in their preferred timezone and format through simple MCP tools.
    2
    -

  • DateTime MCP Server

    TakanariShimbo
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides tools to get the current date and time in various formats (ISO, Unix timestamp, human-readable, custom) with configurable timezone support.
    MIT

  • MCP Time Server

    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.
    6
    476 npm
    2
    MIT