Fantastical now with MCP support for Claude

AI
8

I fed the logs into Claude and got this response. I have not tried it yet:

The Fantastical MCP connector you installed is a local stdio-based MCP server — it’s a native macOS binary that Claude Desktop launches as a child process and communicates with over stdin/stdout (JSON-RPC). Claude.ai on the web can only connect to remote MCP servers that expose an HTTP endpoint (SSE or streamable HTTP transport).

So the core problem is a transport mismatch: Fantastical speaks stdio, Claude.ai speaks HTTP.

Here are your realistic options:

Option 1: Use an MCP Bridge/Proxy (most practical)

Tools like mcp-proxy or supergateway can wrap a local stdio MCP server and expose it as an SSE or HTTP endpoint. The flow would be:

  1. Run a proxy on your Mac that launches the Fantastical binary as a subprocess
  2. The proxy exposes an HTTP SSE endpoint (e.g., http://localhost:8080/sse)
  3. You’d then need to make that endpoint reachable from the internet — via a tunnel like ngrok, Cloudflare Tunnel, or Tailscale Funnel
  4. Add that public URL as a custom MCP server in Claude.ai

Something like:

bash

npx @anthropic/mcp-proxy --transport sse --port 8080 -- \
  "/Users/richardkaplan/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app/Contents/MacOS/FantasticalMCP"

Then tunnel it with ngrok http 8080 or similar.

Key challenges to be aware of:

  • The Fantastical binary likely expects to interact with the Fantastical app on macOS via AppleScript or XPC, so it must run on your Mac — you can’t containerize it elsewhere
  • Your Mac needs to be on and running the proxy whenever you want access from Claude.ai
  • Security: exposing a local MCP server to the internet means anyone with the URL could potentially read/modify your calendar unless you add auth

I also specifically asked it to comment on the reasoning you got as to why it would not work. This is the response:

That response is partially correct but somewhat misleading. Let me clarify based on the logs you shared earlier:

What’s true: The Fantastical connector is distributed as a “Claude Extension” — a bundled macOS app binary that lives in Claude’s Application Support directory. It’s not a standalone MCP server you installed via claude mcp add or from a separate repo. In that sense, it is “built-in” to the Claude Desktop ecosystem.

What’s misleading: It absolutely is a standard MCP server. Your own logs prove this clearly. It speaks JSON-RPC 2.0 with proper MCP protocol negotiation (initialize, notifications/initialized, tools/list), it advertises standard MCP capabilities (tools with listChanged), and it returns well-formed tool definitions with proper inputSchema and annotation hints. The logs show it implementing the MCP spec to the letter, including the newer 2025-03-26 protocol version.

The distinction isn’t “built-in connector vs. MCP server” — it’s stdio transport vs. HTTP transport. It’s a real MCP server that happens to be distributed as a bundled extension and communicates over stdio.

Why claude mcp add-from-claude-desktop may not find it: That command typically looks at the claude_desktop_config.json file where manually-configured MCP servers are listed. Claude Extensions (the newer distribution mechanism) are managed separately by the desktop app, so they wouldn’t show up there. That’s a config discovery issue, not evidence that it’s “not a real MCP server.”

So the bottom line remains what I said before — it’s a legitimate MCP server with a stdio transport, and the proxy/tunnel approach would theoretically work. The binary is the server. The challenge is just bridging stdio to HTTP so Claude.ai can reach it.