时间戳双向转换，时区统一北京时间(UTC+8)。传入 Unix 时间戳（整数秒或毫秒，自动识别；也接受数字字符串）返回 ISO 8601 北京时间字符串；传入日期/时间字符串（如 2026-09-05、2026-09-05 10:30:00、2026-09-05T10:30:00+08:00）返回 Unix 秒/毫秒时间戳；不传 value 返回当前时间的两种格式。
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | iso | |
| value | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有任何 annotations，描述承担了全部行为披露责任。它披露了时区标准化为北京时间(UTC+8)、秒/毫秒自动识别、接受数字字符串、以及缺省 value 时返回当前时间两种格式。主要缺口是 `to` 参数的作用未说明，且'返回 Unix 秒/毫秒时间戳'中的'秒/毫秒'存在歧义——代理无法确定输出究竟选秒、选毫秒、还是两者都返回。
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?
单个前置加载的长句：核心目的+时区在前，随后是分号隔开的三段输入→输出映射，最后是缺省行为。信息密度高但每个成分(时区、自动识别、示例、默认行为)都承载价值，无冗余；因内容过密且存在'秒/毫秒'歧义，未给 5。
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?
对于无 annotations、无 output schema 的双向转换工具，描述覆盖了主要转换流和缺省场景，并给出了格式示例。但 `to` 参数没有任何说明，且 Unix 返回值的秒/毫秒细节含糊——代理若需指定输出格式(如毫秒 vs 秒)将无从下手。考虑到工作中动责较高，描述整体够用但存在真实缺口。
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 为 0%，`value` 的类型是近似无信息的 `anyOf [{}, null]`，因此描述必须补偿。描述对 `value` 的补偿非常充分：整数秒或毫秒、数字字符串、以及带示例的多种日期时间格式(2026-09-05、2026-09-05 10:30:00、2026-09-05T10:30:00+08:00)。但 `to` 参数完全未提及——代理只知道默认值是 'iso'，无法确定其他合法取值及各自行为，这是两个参数中一个完全空白。
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?
描述开门见山地给出'时间戳双向转换'——明确的动词+资源——并定义了时区(UTC+8)和两个转换方向。示例格式和默认行为进一步确认了工具边界。主题上与兄弟工具 convert_unit、format_json、generate_qr、generate_uuid 有清晰区分，代理无需打开 schema 即可判断这是时间戳专用工具。
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?
描述为每种调用场景给出了明确的输入→输出映射：传入 Unix 时间戳返回 ISO 字符串，传入日期/时间字符串返回 Unix 时间戳，不传 value 返回当前时间的两种格式。这构成了清晰的调用时机上下文，但没有显式列举替代工具或排除场景，因此未达到 5。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a distinct operation: timestamp conversion, unit conversion, JSON processing, QR generation, and UUID generation. There is no functional overlap or realistic chance of selecting the wrong tool.
All names follow a clear verb_object snake_case pattern: convert_timestamp, convert_unit, format_json, generate_qr, generate_uuid. The verb prefixes consistently reflect the action category.
Five tools is a well-scoped size for a focused developer utility server; each tool provides a distinct, reusable capability and none feels redundant or extraneous.
Each utility is functionally self-contained: timestamp conversion works in both directions, JSON supports format/minify/validate, QR supports SVG/PNG, and UUID supports v4/v5. The set is a loose collection rather than a tightly defined domain, so common utilities like hashing or base64 are absent, but this is a minor gap rather than a blocking one.