# Use Wait, What Time? with your agent

## Connect

Remote MCP endpoint: https://waitwhattime.com/api/mcp
Transport: Streamable HTTP, JSON responses. No API key. No persistent session or GET event stream. A client that requires an SSE-only endpoint is not supported. Client setup varies; this is a server URL, not an OAuth calendar connection.

Tools: search_time_zones accepts {"query":"London"}; compare_weekly_call accepts the decision object documented below. Tool outputs are read-only and contain both text and structured JSON. HTTP clients can GET /api/zones?q=London and POST the same decision object to /api/compare. See [OpenAPI](https://waitwhattime.com/openapi.json).

## Workflow

1. Ask for the two locations, an actual past reference occurrence and its source-local time, duration, review date, invitation anchor confirmation, optional viewer finish-by time, preferred fixed local hour and four-call versus ongoing scope. Never infer that the organizer's location proves the invitation anchor.
2. Use zone search for suggestions, then confirm ambiguous locations. Use exact IANA identifiers.
3. Send only the decision settings. Unknown fields are rejected. Do not send calendar files, titles, attendees, descriptions, credentials or account identifiers.
4. Show both policies, all four dates with local date rollovers, finish-by conflicts, scenario status and warnings. Preserve the selected scope and review date. A four-call proposal excludes firstExcluded; an ongoing policy extends beyond the forecast.
5. Return the reviewUrl so the person can inspect the comparison. The URL fragment is a readable snapshot, not authorization. A simple HTTP fetch cannot render the browser's fragment-based comparison; use the JSON response or decode the decision fragment as input.
6. Prepare a message or organizer brief. Ask the user to confirm the exact recipients, message and calendar changes before their agent uses separate tools to send or edit. Check the existing series and its exceptions first. No Wait, What Time? response means a calendar was changed.

## Input

Every field is required. cutoff may be an empty string. The following dates are a fixed synthetic example, not today's date:

~~~json
{
  "v": 1,
  "sourceZone": "America/New_York",
  "viewerZone": "Asia/Kolkata",
  "referenceDate": "2026-10-26",
  "referenceTime": "09:00",
  "duration": 30,
  "cutoff": "19:00",
  "knownAnchor": true,
  "scope": "four",
  "choice": "viewer",
  "asOf": "2026-10-31"
}
~~~

- v: Decision input version. Must be 1.
- sourceZone: Confirmed invitation anchor zone, or an explicitly assumed zone when knownAnchor=false. Use a recognized IANA identifier or UTC.
- viewerZone: The other person’s recognized time zone. Must differ from sourceZone.
- referenceDate: Reference call date in sourceZone, 2020–2040, on/before asOf and within 366 days. Prefer a completed call before the clock change.
- referenceTime: Reference call start in sourceZone, using the 24-hour clock.
- duration: Call duration in minutes.
- cutoff: Viewer-local finish-by time, or an empty string to disable the cutoff check.
- knownAnchor: True only if the invitation’s time zone is confirmed. False returns conditional scenarios.
- scope: Propose only the four previewed occurrences, or an ongoing weekly local-time policy.
- choice: Whose reference local start time should remain fixed in the proposed request. Both options are compared.
- asOf: Explicit review date, 2020–2040, interpreted in sourceZone. Occurrences on this date are excluded.

## Output and bounds

Response schemaVersion 1 includes validated input, bundled IANA rulesVersion, reference, both policy options, four exact UTC/local intervals per policy, selectedPolicy, scope, laterTransitions, warnings, proposalText, organizerText and reviewUrl. requiresHumanAgreement is true; calendarChanged is false. firstExcluded is included only for four-call scope.

One request compares one indefinite weekly pattern between two different recognized zones. Request bodies max 16 KiB. Durations 15–180 minutes; dates 2020–2040; reference within 366 days of review. Review-day occurrences are excluded. Missing or repeated clock times in the preview reject the request; later forecast problems are warnings. The forecast covers 52 weekly occurrences. Exceptions, availability, collisions, holidays and future law changes are not resolved.

HTTP success is 200. Malformed JSON 400, disallowed Origin 403, method 405, oversized 413, unsupported media 415, invalid inputs 422 and internal failures 500. Treat errors as errors; do not reuse stale output. MCP tool input failures use isError; transport errors use JSON-RPC errors.

## Privacy

The website checker and copy handoff calculate locally. Pasting a handoff shares those fields with the chosen AI. Explicit MCP/API requests send only the supplied settings to Wait, What Time?'s Vercel functions. The app does not persist request bodies or deliberately log them; ordinary hosting telemetry may be processed by Vercel. No third-party calendar is read or written. A review link reveals its settings to anyone who receives it.

## Protocol references

[Official MCP SDK server guide](https://ts.sdk.modelcontextprotocol.io/server) · [Streamable HTTP specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports) · [Vercel Node.js functions](https://vercel.com/docs/functions/runtimes/node-js)