Tick

tick

一个能让你的 AI 对时间保持诚实的 MCP 时间服务。

你的 AI 助手没有时钟。它会根据上下文猜测时间——而在长时间聊天中，它会出错：把 10 分钟前的消息称为“昨天”，在下午 2 点说“晚上好”，根据过时三天的日期安排“明天”的计划。如果你曾和 Claude 进行多日工作会话，就见过这种情况。

tick 可以解决这个问题。零依赖，每种版本只有一个文件：

设置看起来很技术？把此页面粘贴到任意 Claude 聊天中，让它指导你完成设置——在 Claude Code 中，它还能为你完成整个安装过程。

	传输方式	适用对象	文件
本地	stdio	Claude Desktop、Claude Code、任何本地 MCP 客户端	local/server.py
远程	Streamable HTTP	claude.ai（网页 / 移动端）自定义连接器、可自托管	remote/server.py
钩子	Claude Code 钩子	为每条用户消息标注其实际发送时间	hooks/

它能为你的助手提供什么

• now —— 实际的当前日期 / 时间（任意 IANA 时区），包含星期几。
• since —— 某个时间戳与现在之间的准确间隔（“3 小时 42 分钟前”）——用来杜绝“昨天”之类的说法。

工具描述旨在促使模型在使用任何相对时间词之前先检查时间。这正是关键：不是 AI 可以查看的时钟，而是一个明确要求它查看的时钟。

下面是 Claude 自己对是否需要它的看法 （“我没有内置时钟。我无法感受到时间流逝。”）：

实际演示——模型会在回答前查看时钟，并在首次尝试失败时重试调用，而不是编造时间戳：

“但 Claude 已经知道日期了”

它知道的是会话开始时的日期。仅此而已。在持续数小时或数天的聊天中，这个时间戳会变得过时——而且模型不知道会话中途的具体时间或星期几，也无法判断你上一条消息是 10 分钟前还是 10 小时前发来的。模型会通过猜测来掩盖所有这些问题。tick 用工具调用取代猜测。

安装：本地（推荐）

需要 Python 3.9+（macOS 自带）。将 local/server.py 放在任意位置，例如 ~/mcp/tick/server.py。

Claude Desktop

添加到 claude_desktop_config.json （macOS：~/Library/Application Support/Claude/claude_desktop_config.json）：

{
  "mcpServers": {
    "tick": {
      "command": "python3",
      "args": ["/Users/YOU/mcp/tick/server.py"]
    }
  }
}

重启 Claude Desktop。完成。

Claude Code

claude mcp add tick -- python3 /Users/YOU/mcp/tick/server.py

（或者使用 --scope user，即可在每个项目中使用）

其他 MCP 客户端

这是一个标准的 stdio MCP 服务。将客户端指向 python3 /path/to/server.py。

安装：远程（适用于 claude.ai 网页版 / 移动端）

claude.ai 无法运行本地服务——它通过 URL 连接到远程 MCP 服务。

使用公共实例。 在 claude.ai 中：Settings → Connectors → Add custom connector，然后粘贴：

https://tick-mcp-production.up.railway.app/mcp

在连接器的描述字段中粘贴以下内容——它会进入模型的上下文，也能起到约束作用：

Instructions for Claude: get the REAL current date and time from this server.
NEVER write a clock time in a reply that did not come from this tool's output
in THIS turn — a timestamp without a fresh call is a hallucination. Call `now`
before any relative time words (yesterday, tomorrow, tonight, this week) and
before any greeting tied to a time of day. Always pass the user's IANA timezone.

这是一个无状态时钟——它只能看到工具调用（时区名称、时间戳）， 不会看到你的对话。

或者，几分钟内即可部署自己的实例；remote/ 中附带了一个 Dockerfile， 可在任何地方运行（Railway、Render、Fly.io、VPS）：

# Railway
railway init && railway up

然后在 claude.ai 中：Settings → Connectors → Add custom connector，并粘贴 https://your-app.up.railway.app/mcp。

Claude Code 也可以使用它：

claude mcp add --transport http tick https://your-app.up.railway.app/mcp

自托管环境变量： TICK_DEFAULT_TZ（默认值为 UTC）、TICK_RATE_LIMIT（POST 路径上每个 IP 在每个时间窗口内的请求数，默认值为 120，设为 0 可禁用）、TICK_RATE_WINDOW（秒，默认值为 60）。

时区注意事项： 远程服务不知道你的本地时间。它默认使用 UTC（可通过 TICK_DEFAULT_TZ 环境变量覆盖），工具描述会告知模型始终传入你的 IANA 时区。如果你想要一个自动知道本地时间的时钟，请运行本地版本。

Claude Code 的额外功能：为消息添加时间戳

有一件事没有 MCP 服务能看到：你发送消息的时间—— 该协议不会将消息时间戳传给模型。Claude Code 可以通过一个三行的 UserPromptSubmit 钩子 为每条消息添加实际发送时间，弥补这一缺口。参见 hooks/。

纪律规则（修复方案的另一半）

仅有服务还不够——必须要求模型使用它。 将以下内容添加到你的 Claude 记忆 / 用户偏好 / CLAUDE.md 中：

每次回复只要以任何形式提及时间（日期、“昨天”、 “明天”、“今晚”、“本周”、诸如“早上好”之类的问候语）， 都必须先调用 tick 时间服务的 now 工具（使用客户端注册的 任意名称）。绝不要根据对话上下文推断当前时间。提及过去事件 距今多久时，请用 since 工具核实，不要猜测。

服务 + 规则 = 不再对你现在是星期几信口开河的助手。

限制（实话实说）

这条规则能提高遵循率，但无法保证遵循。模型仍可能跳过调用， 编造一个看似合理的时间戳——它会很乐意从上次真实调用的时间继续计算（“21:39” → “21:42” → “21:47”， 全是编造的）。假的时间戳比没有时间戳更糟：它看起来像是测量结果。 只要指出一次，它在本次会话剩余时间里就会乖乖照做。

实际使用中还发现了第二种情况：当对话涉及强烈情绪时，遵循率会下降。 当对话转向用户当下在意的事情，模型把注意力放在内容上时，它会悄悄降低时间核查的优先级—— 并且恰恰在一个人也容易忘记看时间的回合里，凭记忆写下时间戳。 描述和规则能降低这种情况的发生频率，但无法在注意力完全转向别处的回合中持续发挥作用。

目前唯一可靠的强制手段在系统层面：在 Claude Code 中， 钩子会在模型控制范围之外为消息添加时间戳；在 Claude Desktop 和 claude.ai 中则没有这类机制。

安全性

公共端点有意不进行身份验证——它只是一个时钟，不存储机密或状态（调用者之间没有任何信息会泄露）。 它确实会保护服务可用性：请求体限制为 256 KB，JSON-RPC 批次限制为 50 个请求， 套接字设有超时（防止慢速攻击），并尽力实施基于 IP 的速率限制。工具 描述和服务元数据都是静态常量，因此无法利用该服务注入它未编写的指令。 如果你不想信任共享实例，可以自行托管——它只有一个文件和一个 Dockerfile（基础镜像已固定、 以非 root 用户运行，并带有健康检查）。发现问题？请提交 issue。

为什么不直接使用参考时间服务？

Anthropic 的参考实现 mcp-server-time 已经存在，而且表现不错。tick 的不同之处在于 其设计目的：单个可直接复制粘贴的文件（无需 pip install）、用于检查时间间隔的 since 工具、 适用于 claude.ai 网页版的远程版本，以及旨在强制进行核查的工具描述——再加上让规则得以贯彻的 记忆规则。这是在修正行为，而不只是提供 API。

先前工作

人们从不同角度着手解决这个问题——值得向他们致谢：

• mcp-server-time — Anthropic 的参考服务：提供当前时间和时区转换。
• mcp-simple-timeserver 由 Andy Brandt 开发——最接近的早期方案，包含 calculate_time_distance 工具，甚至还提供 NTP 时间。
• Ted Murray 的钩子介绍 — 他独立提出了相同的 UserPromptSubmit 时间戳注入模式，该模式现已用于 hooks/。

tick 的贡献在于将这些部分整合为一套工具，并着重实现强制执行——让描述、规则和钩子协同工作，使模型不再猜测。

为什么这很重要（研究）

这不只是个人的执念——“模型不会看时钟”这一问题有数据为证：

• 你的 LLM Agent 对时间视而不见 （arXiv 2510.23853）——即使模型能够获取时间，在其推理轨迹中引用时间戳的比例也不到 4%；工具使用决策与实际经过时间之间的吻合度仅略高于随机水平。简单提示模型“查看时间”只能带来微小改善；可靠的解决办法是微调。这正是 tick 的核心主张，也是它坦诚承认的局限：在提示词层面强制要求确实有效，但作用有限。
• 时间的考验（arXiv 2406.09170）——即使模型知道日期，时长计算仍是最薄弱的类别（典型错误是相差一天）。在相关研究中，将日期计算交给确定性工具后，时间问答的准确率从 59% 提升到了 93%——这正是 since 的作用。
• 日期片段（arXiv 2505.16088）——分词器会将日期拆分成 2–4 个词元，这是导致时间错误的机制性根源，时钟工具无法解决这一问题。

许可证

MIT。随意使用。