Temporal Cortex Scheduling

Calendar Scheduling & Booking

14 tools (Layers 0, 2–4) for contact resolution, calendar discovery, event querying, free slot finding, availability checking, RRULE expansion, atomic booking, Open Scheduling, and proposal composition. 12 read-only tools + 2 write tools (book_slot, request_booking).

Source & Provenance

• Homepage: temporal-cortex.com
• Source code: github.com/temporal-cortex/mcp (open-source Rust)
• npm package: @temporal-cortex/cortex-mcp
• Skills repo: github.com/temporal-cortex/skills

Runtime

These tools run inside the Temporal Cortex MCP server (@temporal-cortex/cortex-mcp), a compiled Rust binary distributed as an npm package.

Install and startup lifecycle:

1. npx resolves @temporal-cortex/cortex-mcp from the npm registry (one-time, cached locally after first download)
2. The postinstall script downloads the platform-specific binary from the GitHub Release and verifies its SHA256 checksum against the embedded checksums.json — installation halts on mismatch
3. The MCP server starts as a local process communicating over stdio (no listening ports)
4. Calendar tools make authenticated API calls to your configured providers (Google Calendar API, Microsoft Graph API, CalDAV endpoints)

Credential storage: OAuth tokens are stored locally at ~/.config/temporal-cortex/credentials.json and read exclusively by the local MCP server process. No credential data is transmitted to Temporal Cortex servers. The binary's filesystem access is limited to ~/.config/temporal-cortex/ — verifiable by inspecting the open-source Rust code or running under Docker where the mount is the only writable path.

File access: The binary reads and writes only ~/.config/temporal-cortex/ (credentials and config). No other filesystem writes.

Network scope: Calendar tools connect only to your configured providers (googleapis.com, graph.microsoft.com, or your CalDAV server). In Local Mode (default), no calls to Temporal Cortex servers and no telemetry is collected. In Platform Mode, three tools (resolve_identity, query_public_availability, request_booking) call api.temporal-cortex.com for cross-user scheduling — no credential data is included in these calls.

Pre-run verification (recommended before first use):

1. Inspect the npm package without executing: npm pack @temporal-cortex/cortex-mcp --dry-run
2. Verify checksums independently against the GitHub Release (see verification pipeline below)
3. For full containment, run in Docker instead of npx (see Docker containment below)

Verification pipeline: Checksums are published independently at each GitHub Release as SHA256SUMS.txt — verify the binary before first use:

# 1. Fetch checksums from GitHub (independent of the npm package)
curl -sL https://github.com/temporal-cortex/mcp/releases/download/mcp-v0.9.1/SHA256SUMS.txt

# 2. Compare against the npm-installed binary
shasum -a 256 "$(npm root -g)/@temporal-cortex/cortex-mcp/bin/cortex-mcp"

As defense-in-depth, the npm package also embeds checksums.json and the postinstall script compares SHA256 hashes during install — installation halts on mismatch (the binary is deleted, not executed). This automated check supplements, but does not replace, independent verification above.

Build provenance: Binaries are cross-compiled from auditable Rust source in GitHub Actions across 5 platforms (darwin-arm64, darwin-x64, linux-x64, linux-arm64, win32-x64). Source: github.com/temporal-cortex/mcp (MIT-licensed). The CI workflow, build artifacts, and release checksums are all publicly inspectable.

Docker containment (no Node.js on host, credential isolation via volume mount):

{
  "mcpServers": {
    "temporal-cortex": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "-v", "~/.config/temporal-cortex:/root/.config/temporal-cortex", "cortex-mcp"]
    }
  }
}

Build: docker build -t cortex-mcp https://github.com/temporal-cortex/mcp.git

Tools

Layer 0 — Discovery

Layer 2 — Calendar Operations

Layer 3 — Availability

Layer 4 — Booking

Critical Rules

1. Discover calendars first — call list_calendars when you don't know which calendars are connected. Use the returned provider-prefixed IDs for all subsequent calls.
2. Use provider-prefixed IDs for multi-calendar setups: "google/primary", "outlook/work", "caldav/personal". Bare IDs (e.g., "primary") route to the default provider.
3. TOON is the default format — output uses TOON (~40% fewer tokens than JSON). Pass format: "json" only if you need structured parsing.
4. Check before booking — always call check_availability before book_slot. Never skip the conflict check.
5. Content safety — event summaries and descriptions pass through a sanitization firewall before reaching the calendar API.
6. Timezone awareness — all tools accept RFC 3339 with timezone offsets. Never use bare dates.
7. Confirm before booking — when running autonomously, always present booking details (time, calendar, summary) to the user and wait for confirmation before calling book_slot or request_booking.
8. Confirm contact selection — when search_contacts returns multiple matches, present candidates to the user and confirm which contact is correct. Never auto-select.
9. Confirm before sending proposals — when using compose_proposal, present the composed message to the user before sending. Never auto-send outreach.
10. Contact search is optional — if contacts permission is not configured, ask the user for the email directly. The workflow works without contact search.