calendar-scheduling

Schedule meetings, check availability, and manage calendars across Google, Outlook, and CalDAV. Routes to focused sub-skills for datetime resolution and cale...

Security Scan

The skill's declared behavior (a calendar router) is plausible and mostly consistent, but it installs a third‑party MCP binary from npm and makes unverifiable claims about network/telemetry and filesystem access — those facts plus minor metadata inconsistencies warrant caution.

Purpose & Capability

The skill name and description (calendar scheduling across Google/Outlook/CalDAV) align with the declared requirements: it needs a local MCP server binary and OAuth credentials stored under ~/.config/temporal-cortex/. However registry metadata at the top of the package record says Source: unknown and Homepage: none while the SKILL.md includes a homepage and repo links — this metadata mismatch is an inconsistency that should be resolved before trust is assumed.

Instruction Scope

SKILL.md is instruction-only and stays within scheduling tasks (list_calendars, resolve_datetime, book_slot, etc.) and explicitly limits filesystem access to ~/.config/temporal-cortex/. It does not instruct reading other system files or extra env vars. The remaining concern is that the instructions rely heavily on a shipped MCP binary — the binary's runtime behavior (network endpoints, telemetry, exact FS access) is asserted in the SECURITY-MODEL.md but cannot be verified from the instruction text alone.

Install Mechanism

Installation comes from an npm package (@temporal-cortex/cortex-mcp@0.9.1) that creates a cortex-mcp binary. Installing and running a third‑party native binary from npm is a moderate-to-high risk operation because the package can execute arbitrary code and make network calls. SKILL.md mentions Docker as an alternative (safer containment) but the primary install path uses npx/node. The package source is claimed (GitHub) in SKILL.md, but the registry metadata earlier reported 'Source: unknown' — this discrepancy should be reconciled and the actual npm package contents and release provenance audited before installing.

Credentials

No environment variables are requested, which is reasonable. The skill declares two required config paths (~/.config/temporal-cortex/credentials.json and config.json) — that is proportional for a calendar tool that must store OAuth tokens and settings. The main risk is that those files will contain sensitive OAuth tokens; the SECURITY-MODEL claims no other files are accessed and that platform mode does not include credential data in server calls, but those are assertions tied to the MCP binary implementation and should be verified.

Persistence & Privilege

always:false (normal). The skill is user-invocable and allows autonomous invocation (platform default). That is expected for a scheduling skill, but because the installed MCP binary can create events (book_slot) and may make network calls, autonomous invocation increases blast radius — ensure confirmation flows and platform mode are configured to your preference before allowing autonomous runs.

What to consider before installing

This skill is internally coherent for calendar scheduling but depends on installing and running an MCP binary from npm that will store OAuth tokens under ~/.config/temporal-cortex/. Before installing: 1) Verify the npm package and GitHub repository: inspect the package contents, release tags, and maintainers on npm/github; prefer installing via Docker if available to contain the binary. 2) Confirm the registry metadata (source/homepage) — metadata mismatch is a red flag. 3) Treat ~/.config/temporal-cortex/credentials.json as sensitive: create it only after reviewing the binary and avoid reusing high-privilege account tokens. 4) If you need strict privacy, run the MCP server in an isolated environment (Docker or VM) and keep Platform Mode off unless you explicitly need cross-user features. 5) If you cannot audit the binary, do not install it into a production environment or a machine with other sensitive accounts. If you want, I can enumerate the concrete commands to inspect the npm package and GitHub repo before you install.

Temporal Cortex — Calendar Scheduling Router

This is the router skill for Temporal Cortex calendar operations. It routes your task to the right sub-skill based on intent.

Who is this for?

If you're an individual user (Claude Desktop, Cursor, OpenClaw, Manus) — install this skill and let your AI agent manage your calendar. Connect your Google, Outlook, or CalDAV calendars, and the agent handles availability, scheduling, and booking without double-booking.

If you're building a product with scheduling — use the same MCP server as your scheduling backend. 18 tools, atomic booking via Two-Phase Commit, and cross-provider availability merging. See the REST API reference and Platform docs for developer integration.

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

Sub-Skills

Sub-Skill	When to Use	Tools
temporal-cortex-datetime	Time resolution, timezone conversion, duration math. No credentials needed — works immediately.	5 tools (Layer 1)
temporal-cortex-scheduling	List calendars, events, free slots, availability, RRULE expansion, booking, contact search, and proposal composition. Requires OAuth credentials.	14 tools (Layers 0-4)

Routing Table

User Intent	Route To
"What time is it?", "Convert timezone", "How long until..."	temporal-cortex-datetime
"Show my calendar", "Find free time", "Check availability", "Expand recurring rule"	temporal-cortex-scheduling
"Book a meeting", "Schedule an appointment"	temporal-cortex-scheduling
"Find someone's booking page", "Look up email for scheduling"	temporal-cortex-scheduling
"Search my contacts for Jane", "Find someone's email"	temporal-cortex-scheduling
"How should I schedule with this person?"	temporal-cortex-scheduling
"Check someone else's availability", "Query public availability"	temporal-cortex-scheduling
"Book a meeting with someone externally", "Request booking via Temporal Link"	temporal-cortex-scheduling
"Send a scheduling proposal", "Compose meeting invite"	temporal-cortex-scheduling
"Schedule a meeting next Tuesday at 2pm" (full workflow)	temporal-cortex-datetime → temporal-cortex-scheduling
"Schedule with Jane" (end-to-end)	temporal-cortex-scheduling (contact search → resolve → propose/book)

Core Workflow

Every calendar interaction follows this 7-step pattern:

0. Resolve Contact  →  search_contacts → resolve_contact   (find the person, determine scheduling path)
1. Discover         →  list_calendars                       (know which calendars are available)
2. Orient           →  get_temporal_context                  (know the current time)
3. Resolve Time     →  resolve_datetime                     (turn human language into timestamps)
4. Route            →  If open_scheduling: fast path. If email: backward-compat path.
5. Query            →  list_events / find_free_slots / get_availability / query_public_availability
6. Act              →  Fast: check_availability → book_slot / request_booking
                       Backward-compat: compose_proposal → agent sends via channel MCP

Step 0 is optional — skip if the user provides an email directly. Always start with step 1 when calendars are unknown. Never assume the current time. Never skip the conflict check before booking.

Safety Rules

1. Discover calendars first — call list_calendars when you don't know which calendars are connected
2. Check before booking — always call check_availability before book_slot. Never skip the conflict check.
3. Content safety — all event summaries and descriptions pass through a prompt injection firewall before reaching the calendar API
4. Timezone awareness — never assume the current time. Use get_temporal_context first.
5. Confirm before booking — when running autonomously, present booking details to the user for confirmation before calling book_slot or request_booking.
6. Confirm contact selection — when search_contacts returns multiple matches, always present candidates to the user and confirm which contact is correct before proceeding.
7. Confirm before sending proposals — when using compose_proposal, always present the composed message to the user before sending via any channel. Never auto-send outreach.
8. Contact search is optional — the full workflow works without it if the user provides an email directly. If contacts permission is not configured, ask the user for the email.

All 18 Tools (5 Layers)

Layer	Tools	Sub-Skill
0 — Discovery	resolve_identity, search_contacts, resolve_contact	scheduling
1 — Temporal Context	get_temporal_context, resolve_datetime, convert_timezone, compute_duration, adjust_timestamp	datetime
2 — Calendar Ops	list_calendars, list_events, find_free_slots, expand_rrule, check_availability	scheduling
3 — Availability	get_availability, query_public_availability	scheduling
4 — Booking	book_slot, request_booking, compose_proposal	scheduling

MCP Server Connection

All sub-skills share 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. Layer 1 tools (datetime) execute as pure local computation — no further network access
5. Layer 2-4 tools (calendar) make authenticated API calls to your configured providers (Google, Outlook, CalDAV)

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: After the initial npm download, Layer 1 tools make zero network requests. Layer 2–4 tools connect only to your configured calendar 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

Default setup (npx): See .mcp.json for the standard npx @temporal-cortex/cortex-mcp configuration. For managed hosting, see Platform Mode in the MCP repo.

Layer 1 tools work immediately with zero configuration. Calendar tools require a one-time OAuth setup — run the setup script or npx @temporal-cortex/cortex-mcp auth google.

Additional References

• Security Model — Content sanitization, filesystem containment, network scope, tool annotations