F
licenseNot graded
qualityD
maintenanceFacilitates note storage and summarization through custom URIs, allowing users to manage, summarize, and update notes with varying detail levels in a collaborative environment.
-
Datetime MCP Server
by bossjones
日期时间 MCP 服务器
MCP（模型完成协议）服务器提供日期时间功能以及简单的注释管理。
概述
该服务器实现了 MCP 协议并提供各种与日期时间相关的工具和资源，包括：
不同格式的当前日期和时间
日期格式化实用程序
活动安排提示
简单的笔记管理功能
任何 MCP 客户端都可以使用该服务器来访问日期和时间信息并管理简单的笔记。
Related MCP server: browser-use MCP server
特征
资源
服务器提供以下资源：
datetime://current- 当前日期和时间datetime://today- ISO 格式的今日日期datetime://time- 24 小时格式的当前时间note://internal/{name}- 用户创建的注释
工具
该服务器提供以下工具：
add-note- 添加带有名称和内容的新注释get-current-time- 以各种格式获取当前时间（ISO、可读、Unix 时间戳、RFC3339）format-date- 根据指定的格式模式格式化日期字符串
提示
服务器给出如下提示：
summarize-notes- 创建所有笔记的摘要schedule-event- 帮助在特定时间安排事件
安装
克隆存储库：
git clone https://github.com/bossjones/datetime-mcp-server.git
cd datetime-mcp-server创建虚拟环境：
uv venv
source .venv/bin/activate安装依赖项：
uv sync用法
运行服务器
运行服务器：
uv run python -m datetime_mcp_server.server服务器将启动并在 stdin/stdout 上监听 MCP 协议消息。
连接到服务器
您可以使用任何 MCP 客户端连接到服务器。例如，使用 MCP CLI：
uv run mcp connect datetime-mcp-server发展
安装开发依赖项
# Install all dependencies including development dependencies
uv sync --dev运行测试
运行测试：
uv run pytest tests/单元测试
单元测试验证各个服务器功能是否正常工作：
uv run pytest tests/acceptance/test_server.py集成测试
集成测试验证服务器是否正确实现了 MCP 协议：
uv run pytest tests/acceptance/test_server_integration.py依赖管理
# 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示例
使用 MCP CLI 的服务器
列出可用资源：
uv run mcp resources list读取日期时间资源：
uv run mcp resources read datetime://current添加注释：
uv run mcp tools call add-note --arguments '{"name": "meeting", "content": "Team meeting at 3pm"}'获取 ISO 格式的当前时间：
uv run mcp tools call get-current-time --arguments '{"format": "iso"}'格式化日期：
uv run mcp tools call format-date --arguments '{"date": "2023-10-15", "format": "%B %d, %Y"}'Makefile 任务
该项目包括几个 Makefile 任务来简化开发：
# Sync all dependencies with frozen lockfile
make uv-sync-all
# Sync only development dependencies
make uv-sync-dev
# Run tests
make test构建和发布
准备分发包：
同步依赖项并更新锁文件：
uv sync构建软件包分发版：
uv build这将在dist/目录中创建源和轮子分布。
发布到 PyPI：
uv publish注意：您需要通过环境变量或命令标志设置 PyPI 凭据：
令牌：
--token或UV_PUBLISH_TOKEN或用户名/密码：
--username/UV_PUBLISH_USERNAME和--password/UV_PUBLISH_PASSWORD
调试
由于 MCP 服务器通过 stdio 运行，调试起来可能比较困难。为了获得最佳调试体验，我们强烈建议使用MCP Inspector 。
您可以使用以下命令通过npm启动 MCP Inspector：
npx @modelcontextprotocol/inspector uv --directory /Users/malcolm/dev/bossjones/datetime-mcp-server run datetime-mcp-server启动后，检查器将显示一个 URL，您可以在浏览器中访问该 URL 以开始调试。
执照
麻省理工学院
贡献
分叉存储库
创建功能分支
进行更改
使用
uv run pytest运行测试提交拉取请求
Available Tools
3 toolsadd-noteC
Add a new note
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | Yes |
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
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date string to format (default: today) | |
| format | Yes | Format 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
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Format to return the time in | |
| timezone | No | Optional 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.
3 tool updates
- First observed
add-note - First observed
format-date - First observed
get-current-time
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
Related MCP Connectors
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Cross-session, cross-device memory for your agent: remember and recall notes. No key to start.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
past.dev is a long-term memory API for AI agents. Send it timestamped text such as emails, meeting transcripts and support tickets. Ask a question and get the current fact, the value it replaced and the source behind it. With this server, your assistant can recall and save memory and manage your past.dev account.
Related MCP Servers
- FlicenseCqualityDmaintenanceThis server provides a note storage system with a custom URI scheme, allowing users to add and summarize notes, with adjustable summary detail levels.1-
- FlicenseBqualityDmaintenanceA server for managing and summarizing notes using a custom URI scheme, with tools to add notes and create styled summaries.418-
- FlicenseNot gradedqualityDmaintenanceA simple note-taking MCP server that allows storing and summarizing notes with custom URI schemes and provides functionality to add notes and generate summaries with different detail levels.5-