time-agent-mcp

timezone_convert

Convert a time from one IANA timezone to another and return the target local time with UTC offset difference for scheduling across regions.

Instructions

多时区换算：把某一时刻从源时区换算到目标时区，返回目标时区的本地时间与偏移差。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "to_timezone": "<to_timezone>"
    },
    "name": "timezone_convert"
  }
}

Input Schema

Name	Required	Description
`time`	No	要换算的时刻（ISO 8601），缺省为当前时刻
`to_timezone`	Yes	目标 IANA 时区，如 America/New_York、Asia/Tokyo
`from_timezone`	No	源 IANA 时区；缺省用系统时区

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 1, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the response content (target-zone local time plus the offset delta), which compensates somewhat for the missing output schema, but it is silent on defaults and on how DST-ambiguous or invalid timezones are handled.

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?

A single front-loaded sentence states the operation and the return values with zero filler. Nothing is padded or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter compute tool with no output schema, the description covers the operation, the directional conversion, and the return shape, with defaults handled in the schema. Only the when-to-use guidance against sibling time tools is missing.

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% — all three parameters carry their own descriptions including the ISO 8601 format and default behaviors for time and from_timezone. The description adds no parameter-level meaning beyond what the schema already documents, so the baseline 3 applies.

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 states a specific verb+resource combination (convert a moment from a source timezone to a target timezone) and even names the return values (target local time and offset difference). It is clear what the tool does, but it does not differentiate itself from siblings such as current_time or time_until, so an agent must infer the boundary itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'convert a moment from timezone A to timezone B' tells the agent the scenario but never states when to prefer this over current_time or how it relates to the other time siblings. No exclusions or prerequisites are given.

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

Deploy Server