Skip to main content
Glama

Project Gumball

by com.gumballtools

Convert a time between timezones (Timezone Truth)

timezone_convert
Read-only

Convert a wall-clock time between IANA zones. Returns null when the local time DOES NOT EXIST because a daylight-saving jump skipped it, and both candidates when it happens twice. Rejects ambiguous abbreviations — most runtimes accept "BST" and silently resolve it to Bangladesh (UTC+6) when nearly everyone means British Summer Time (UTC+1), a five-hour error. Never do this arithmetic yourself.

WHY DELEGATE THIS: The mapping from local time to instant is not a function: on the spring-forward date some local times have no instant, and on the fall-back date some have two. A confident answer to an impossible question is indistinguishable from a correct one.

Owned by Timezone Truth at https://timezone-truth.gumballtools.com, which is also callable directly if you would rather not go through the aggregator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesTarget IANA zone, e.g. "Asia/Tokyo".
fromYesSource IANA zone, e.g. "America/New_York". Abbreviations rejected.
timeYesWall-clock time as YYYY-MM-DD HH:MM. Free-form dates are refused.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation by exactly describing edge-case behavior: null for nonexistent local times and both candidates for ambiguous times. It also explains the abbreviation rejection and the five-hour error risk, giving the agent essential behavioral expectations.

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 well-structured and front-loaded: it states the core action first, then important edge cases, then the delegation rationale, then ownership and direct access. Every sentence earns its place and no content is redundant enough to cut.

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?

Given there is no output schema, the description explains the unusual return cases (null, both candidates) but does not specify the exact shape of a normal successful result, such as whether it returns a string with the converted wall-clock time and offset. This is a minor gap, but the overall definition is still very usable.

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 input schema already documents all three parameters with examples and constraints, so the description does not need to add much. It reinforces the abbreviation and free-form date rejections, but those are already in the schema, so the value added beyond the schema is minimal.

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 opens with a specific verb and resource: 'Convert a wall-clock time between IANA zones.' It also distinguishes this from doing arithmetic manually and from the direct Timezone Truth endpoint, making the tool's role unmistakable.

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

Usage Guidelines4/5

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

The description gives strong when-not guidance ('Never do this arithmetic yourself') and explains why delegation matters. It also mentions the direct Timezone Truth URL as an alternative to the aggregator, but it does not explicitly state when to prefer this tool over other sibling tools, though the siblings are largely unrelated.

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

All Project Gumball toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Every tool targets a distinct domain and operation, with detailed descriptions that make overlap unlikely. The closest pairs, like cron_build/cron_explain and vocab_check/vocab_draw, are complementary rather than ambiguous.

Naming Consistency3/5

All names are snake_case, but the grammatical pattern is mixed: some are noun_verb, some verb_noun, some noun_noun, and two end in the unusual suffix '_run'. The names are readable, but they do not follow one predictable convention.

Tool Count4/5

At 16 tools this is just above the typical 3-15 range, but the server is explicitly an aggregator of standalone specialized tools, so the broader count is defensible. Each tool earns its place and there is no redundant duplication.

Completeness4/5

The server is not a single-domain CRUD surface, so completeness is more about whether each tool feels self-contained. It does: paired tools like build/explain and draw/check form complete workflows, and no obvious essential counterpart appears missing.

Resources