Skip to main content
Glama
enesjakozh
bossjones

Datetime MCP Server

by bossjones
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

Servidor MCP de fecha y hora

Un servidor MCP (Protocolo de finalización de modelos) que proporciona funcionalidad de fecha y hora junto con una gestión sencilla de notas.

Descripción general

Este servidor implementa el protocolo MCP y ofrece varias herramientas y recursos relacionados con la fecha y hora, incluidos:

  • Fecha y hora actuales en diferentes formatos

  • Utilidades de formato de fecha

  • Indicaciones para la programación de eventos

  • Funcionalidad de gestión de notas sencilla

Cualquier cliente MCP puede utilizar el servidor para acceder a información de fecha y hora y administrar notas simples.

Related MCP server: browser-use MCP server

Características

Recursos

El servidor proporciona los siguientes recursos:

  • datetime://current - La fecha y hora actuales

  • datetime://today - Fecha de hoy en formato ISO

  • datetime://time - La hora actual en formato de 24 horas

  • note://internal/{name} - Notas creadas por el usuario

Herramientas

El servidor proporciona las siguientes herramientas:

  • add-note - Agrega una nueva nota con un nombre y contenido

  • get-current-time : obtiene la hora actual en varios formatos (ISO, legible, marca de tiempo Unix, RFC3339)

  • format-date - Formatea una cadena de fecha según un patrón de formato especificado

Indicaciones

El servidor proporciona las siguientes indicaciones:

  • summarize-notes : crea un resumen de todas las notas

  • schedule-event : ayuda a programar un evento en un momento específico

Instalación

  1. Clonar el repositorio:

git clone https://github.com/bossjones/datetime-mcp-server.git
cd datetime-mcp-server

  1. Crear un entorno virtual:

uv venv
source .venv/bin/activate

  1. Instalar las dependencias:

uv sync

Uso

Ejecución del servidor

Para ejecutar el servidor:

uv run python -m datetime_mcp_server.server

El servidor se iniciará y escuchará en stdin/stdout los mensajes del protocolo MCP.

Conectarse al servidor

Puede conectarse al servidor mediante cualquier cliente MCP. Por ejemplo, mediante la CLI de MCP:

uv run mcp connect datetime-mcp-server

Desarrollo

Instalación de dependencias de desarrollo

# Install all dependencies including development dependencies
uv sync --dev

Ejecución de pruebas

Para ejecutar las pruebas:

uv run pytest tests/

Pruebas unitarias

Las pruebas unitarias verifican que las funciones individuales del servidor funcionen correctamente:

uv run pytest tests/acceptance/test_server.py

Pruebas de integración

Las pruebas de integración verifican que el servidor implementa correctamente el protocolo MCP:

uv run pytest tests/acceptance/test_server_integration.py

Gestión de dependencias

# Add a production dependency
uv add package_name

# Add a development dependency
uv add --dev package_name

# Sync dependencies from lockfile
uv sync --frozen

# List outdated packages
uv outdated

Ejemplos

Uso del servidor con MCP CLI

Enumere los recursos disponibles:

uv run mcp resources list

Leer un recurso de fecha y hora:

uv run mcp resources read datetime://current

Añadir una nota:

uv run mcp tools call add-note --arguments '{"name": "meeting", "content": "Team meeting at 3pm"}'

Obtenga la hora actual en formato ISO:

uv run mcp tools call get-current-time --arguments '{"format": "iso"}'

Formatear una fecha:

uv run mcp tools call format-date --arguments '{"date": "2023-10-15", "format": "%B %d, %Y"}'

Tareas de Makefile

El proyecto incluye varias tareas Makefile para agilizar el desarrollo:

# Sync all dependencies with frozen lockfile
make uv-sync-all

# Sync only development dependencies
make uv-sync-dev

# Run tests
make test

Construcción y publicación

Para preparar el paquete para su distribución:

  1. Sincronizar dependencias y actualizar el archivo de bloqueo:

uv sync

  1. Distribuciones de paquetes de compilación:

uv build

Esto creará distribuciones de origen y de rueda en el directorio dist/ .

  1. Publicar en PyPI:

uv publish

Nota: Deberás configurar las credenciales de PyPI a través de variables de entorno o indicadores de comando:

  • Token: --token o UV_PUBLISH_TOKEN

  • O nombre de usuario/contraseña: --username / UV_PUBLISH_USERNAME y --password / UV_PUBLISH_PASSWORD

Depuración

Dado que los servidores MCP se ejecutan en stdio, la depuración puede ser complicada. Para una experiencia óptima, recomendamos usar el Inspector MCP .

Puede iniciar el Inspector MCP a través de npm con este comando:

npx @modelcontextprotocol/inspector uv --directory /Users/malcolm/dev/bossjones/datetime-mcp-server run datetime-mcp-server

Al iniciarse, el Inspector mostrará una URL a la que podrá acceder en su navegador para comenzar a depurar.

Licencia

Instituto Tecnológico de Massachusetts (MIT)

Contribuyendo

  1. Bifurcar el repositorio

  2. Crear una rama de características

  3. Realiza tus cambios

  4. Ejecute las pruebas con uv run pytest

  5. Enviar una solicitud de extracción

Available Tools

3 tools
add-noteC

Add a new note

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
contentYes

TDQS

C2.8/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 only says 'Add a new note' and provides no details on side effects, permissions, return values, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no wasted words, making it concise and front-loaded. However, it is under-specified for the tool's complexity, though this is largely a completeness issue rather than a conciseness issue.

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 lack of annotations, output schema, and parameter descriptions, a five-word description is insufficient for an agent to invoke the tool correctly. The meaning of the parameters and expected return behavior remain ambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero description coverage for the two required parameters ('name' and 'content'), and the description does not explain their meaning or format. The agent cannot infer what 'name' or 'content' represent.

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 ('Add') and a specific resource ('note'), clearly stating the tool's function. It differentiates itself from the sibling 'get_report', which is a read operation.

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 versus alternatives. The description only states the action without any context about when to invoke it or when to choose a sibling tool.

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

format-dateC

Format a date string according to the specified format

ParametersJSON Schema
NameRequiredDescriptionDefault
dateNoDate string to format (default: today)
formatYesFormat string (e.g., '%Y-%m-%d %H:%M:%S')

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't cover important aspects like error handling, input validation, timezone considerations, or output format details. This is inadequate for a tool with potential complexity in date parsing.

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, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for this simple tool and gets straight to the point.

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?

For a date formatting tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format strings are supported, how date strings should be formatted, what happens with invalid inputs, or what the output looks like. The agent would need to guess about important behavioral aspects.

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 already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage.

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 clearly states the verb ('format') and resource ('date string'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-current-time' which might also handle date/time operations, so it doesn't reach the highest score.

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 versus alternatives. The description doesn't mention sibling tools or contexts where this formatting operation is appropriate, leaving the agent without usage context.

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

get-current-timeB

Get the current time in various formats

ParametersJSON Schema
NameRequiredDescriptionDefault
formatYesFormat to return the time in
timezoneNoOptional timezone (default: local system timezone)

TDQS

B3.1/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 mentions the tool returns time 'in various formats' but doesn't specify what those formats are, whether the operation is read-only, if there are rate limits, or how errors are handled. This leaves significant behavioral aspects unclear for the agent.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the core functionality, making it easy for an agent to parse quickly.

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 tool with two parameters and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like error handling or return formats, which would help the agent use it correctly despite the absence of annotations.

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 description mentions 'various formats', which aligns with the 'format' parameter's enum values in the schema. However, with 100% schema description coverage, the schema already documents both parameters thoroughly. The description adds minimal value beyond what the structured schema provides, meeting the baseline for high coverage.

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 clearly states the tool's purpose ('Get the current time') and specifies the scope ('in various formats'), which distinguishes it from potential time-related operations. However, it doesn't explicitly differentiate from sibling tools like 'format-date', which might handle date formatting rather than current time retrieval.

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 like 'format-date'. It doesn't mention prerequisites, limitations, or scenarios where this tool is preferred, leaving the agent to infer usage from the tool name alone.

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. 3 tool updates
    • First observedadd-note
    • First observedformat-date
    • First observedget-current-time
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

C2.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: add-note handles note creation, format-date processes date formatting, and get-current-time retrieves current time. The descriptions are specific and unambiguous, making tool selection straightforward for an agent.

Naming Consistency2/5

The naming is inconsistent with mixed conventions: add-note uses kebab-case, format-date uses kebab-case, and get-current-time uses kebab-case but has a longer name. While all are kebab-case, the verb styles vary (add, format, get), and the lack of a uniform pattern (e.g., all starting with 'get_' or using consistent verb forms) reduces predictability.

Tool Count3/5

With only 3 tools, the count feels thin for a 'Datetime MCP Server' as it suggests limited functionality. While the tools cover basic datetime operations, the server's name implies a broader scope that might include more operations like date parsing, timezone handling, or interval calculations, making this borderline appropriate.

Completeness2/5

The tool surface has significant gaps for a datetime server: it lacks core operations such as parsing dates, calculating differences between dates, handling timezones, or converting between formats. The existing tools (add-note, format-date, get-current-time) do not provide a complete CRUD/lifecycle coverage for datetime manipulation, leading to potential agent failures in common scenarios.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches