Tracks conversation timing by updating a heartbeat timestamp and returning the interval since the last exchange plus total session duration, helping time-blind models perceive dialogue gaps.
会话心跳：每次对话调用一次，更新时间戳并返回距上次对话间隔与本会话总时长，让模型感知对话间隔。
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | 返回时间所用的 IANA 时区，缺省系统时区 | |
| session_id | No | 会话 id，缺省为 default；同一客户端可固定一个 id 以累计会话时长 |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key hidden trait: it is a state-mutating call that updates a timestamp, despite looking like a harmless clock query. It also states the two values returned. It omits any note on persistence, permissions, or what happens on concurrent/first-ever calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with the action, cadence and return payload front-loaded; almost nothing is wasted. It is slightly packed with three ideas at once, but none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-param tool with no output schema and no annotations, the description covers purpose, cadence and return values, which is close to sufficient. Missing only the edge-case behaviour (first call with no prior timestamp, per-session accumulation semantics) and sibling disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so timezone and session_id are already fully documented in the schema (including the default and the accumulation behaviour). The description adds nothing about either parameter, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (会话心跳/更新 time stamp) and its two outputs (距上次对话间隔、本会话总时长), so the verb+resource+return is clear. It does not, however, distinguish itself from near-neighbours such as duration_elapsed or current_time, which also deal with elapsed time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit invocation cadence: '每次对话调用一次' — an agent knows exactly when to fire it. It offers no when-not condition and never routes to the overlapping siblings (duration_elapsed, current_time), so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.