Giving Claude real tools.

The problem

A language model is confident and often wrong about the small factual things an assistant lives on. Ask it what time it is in Berlin right now, or when a Cape Town and a New York calendar actually overlap, and it will produce a plausible answer with no way to know if it is correct. For scheduling across an executive's timezones, plausible is not good enough.

The Model Context Protocol is the fix. It is the standard way to hand a model real tools: functions it can call, with typed inputs and real answers. So instead of asking Claude to reason about time, I gave it the ability to compute it.

What I built

A single-file MCP server in TypeScript that exposes two tools:

• time_in: the current local time in any IANA timezone
• working_hours_overlap: the hours today when two or more timezones share a working day
• draft_calendar_hold: turn a meeting into a ready-to-save .ics invite
• zod input schemas: validate every input before any logic runs
• graceful errors: a bad timezone returns a clean message, never a crash
• stdio transport: Claude launches the server and talks to it directly

Claude reads each tool's description to decide when to call it. When I ask it to schedule a call between Berlin and New York, it reaches for working_hours_overlap on its own and answers from my code.

The engineering, not the prompt

The point of this build was to work below the layer I usually work at. Three decisions carry it:

None of that is visible when the tool works. It is the difference between a demo and something you would let an assistant rely on.

What it returns

working_hours_overlap · Europe/Berlin + America/New_York

When two zones can never align a normal workday, it says so plainly rather than inventing a slot.

Outcome

This is me moving from wiring tools together to building them. The next tools an assistant reaches for, a free-slot finder and a meeting brief, follow the same shape.