Loading ToolBench
Cursor MCP Server using WorldTime API and TimezoneDB
The server implements 4 tools with basic functionality but exhibits significant quality gaps across naming, descriptions, schema completeness, and error handling. All tools are READ_ONLY and properly declared. However, parameter descriptions are often missing or generic, schemas lack validation constraints, and error messages provide no recovery guidance. The tool definitions are explicitly visible in src/index.ts with Zod schema usage, but the implementation has notable deficiencies that would hinder production LLM agent usage.
Given a UTC time, find the time in a different timezone
Get the current time and timezone for an IP address
Get local time, GMT offset, DST of a place by latitude & longitude, timezone name, abbreviation, city name, or IP address.
List out all available time zones supported by TimeZoneDB.
Tool descriptions lack sufficient detail to guide LLM selection. 'List out all available time zones supported by TimeZoneDB' (41 chars) and 'Get the current time and timezone for an IP address' (52 chars) are too terse. Missing WHEN to use each tool and what it returns.
Parameter descriptions are missing or insufficient. 'get-timezone' has latitude and longitude marked optional but no explanation of what they do when provided vs. the timezone parameter. 'convert-timezone' dateToConvert description is vague about expected format details. No indication of which parameters are required.
Schemas lack validation constraints. IP validation uses Zod .ip() for get-timezone-by-ip (good), but latitude/longitude have no min/max bounds (must be -90 to 90 and -180 to 180). Timezone strings accept free-form input with no enum constraint. dateToConvert union type lacks format specification beyond 'UTC epoch time or a date string'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Error responses are generic and provide no recovery guidance. All tools return bare error text ('Error fetching time data from TimezoneDB', 'Error fetching time data by your IP address from WorldTimeAPI') without telling the LLM why it failed, whether to retry, or what to do next. Per pattern:recovery-guide, errors must be actionable.
Tool naming ambiguity and composition concerns. 'get-timezone' is overloaded, it accepts either a timezone name OR latitude/longitude, with optional latitude/longitude that conditionally change behavior. Per pattern:tool, each tool should do exactly one thing. The parameter dependency (if latitude and longitude provided, use position; else use zone) is undocumented.
Output schemas are not documented. Tools return content arrays with text fields, but the response shape (always content array with type='text'?) is not formally specified. LLMs cannot plan downstream calls without knowing the output structure.
Secrets exposed via environment variables but no validation that TIMEZONE_DB_API_KEY is set. If missing, all TimezoneDB tools will silently fail with ambiguous 'Error fetching' messages. No guidance on required secrets or setup steps.
Response text is repetitive and confusing. 'get-timezone' output reads 'The local time in ${data.countryName} ${data.zoneName} ${data.abbreviation} is ${data.formatted} in ${data.zoneName} ${data.abbreviation}', redundant zone info. 'convert-timezone' output contains malformed logic and contradictory statements ('would be ${timezone2Time} ${toAbbreviation} in ${timezone1}'). Responses should be concise and unambiguous.
No pagination or result limits declared. 'list-timezones' returns all available timezones with no mention of pagination, limit, or total count. If the API returns thousands of zones, the response will bloat the context window and degrade LLM reasoning.