Evite Mcp

evite-mcp

[CI] [npm] [license]

A Model Context Protocol server for Evite — read and act on your events as both guest (invitations received) and host (events you created): list events, view guest lists & RSVP tallies, RSVP, message guests, and create/edit events. Built on @chrischall/mcp-utils.

Status: read + write tools live. The five read tools work against Evite's internal API, authenticating from email/password (tier-1, POST /ajax_login), a raw cookie env var, or a signed-in browser tab (fetchproxy bootstrap). The thirteen write tools ask you to confirm first — nothing is sent until you approve (see Confirmations) — and their endpoints are live-verified (see docs/EVITE-API.md); a couple of request bodies are still assumed rather than captured (#3).

Tools

Six read tools (all read-only), thirteen confirmed write tools, evite_upload_slots (read-only: upload links for photos on the hosted connector), plus evite_healthcheck:

Write tools (confirmed)

Every write tool asks you to confirm before it sends anything. A client that can show a confirmation prompt (Claude Code) shows one with the exact values that would be sent (unless MCP_CONFIRM_ELICITATION=off). Elsewhere (claude.ai, Claude Desktop) the first call performs no write (at most a read-only lookup — e.g. evite_update_guest reads the draft guest list to build an exact preview) and returns that preview plus a confirmToken; only a repeat call with the token performs the write. The token is single-use, expires, and is bound to the tool and the exact values — change anything and it is refused (DRAFT_CHANGED) with a fresh preview. See Confirmations. Endpoints are verified; the CSRF token (X-CSRFToken, read fresh per request as it rotates) is attached centrally.

The authoring flow is evite_create_event → evite_add_guest → evite_send. evite_send, evite_send_message, evite_broadcast, and evite_cancel_event have real-world effects (emails / cancellation notices), so their confirmation matters.

Confirmations

Photo uploads

evite_upload_photo takes the image as exactly one of three inputs (JPEG/PNG/GIF/WebP/HEIC, max 20 MB; the bytes must really be that image type, whatever the name says):

• path — local installs only. A file inside EVITE_UPLOAD_DIR (below).
• inline — { filename, content_base64 }. Works anywhere; meant for a small photo, since every byte rides inside the tool call.
• blob_key — the hosted connector's way in. It cannot read files on your machine, so a path is refused there with directions. Instead, call evite_upload_slots with the filenames; each slot has a signed uploadUrl and a ready curl command that PUTs the file with the exact Content-Type. Then pass the slot's blobKey as blob_key. The upload is read on the preview and again on confirm, and its SHA-256 is bound into the confirmation, so a file replaced in between is refused (DRAFT_CHANGED). It is deleted only after Evite accepts the photo (the result's blob says whether that delete worked). If the upload fails it is kept, so a retry can reuse the same blob_key. evite_upload_slots refuses on a local install, which has no blob store.

Architecture

Fetchproxy-archetype MCP. Evite has no public API, so the server calls Evite's internal /services/ web API using your session. src/auth.ts resolves that session in priority order:

1. EVITE_EMAIL + EVITE_PASSWORD (tier-1, preferred) — headless email/password form login: POST the creds to https://www.evite.com/ajax_login, then build the session from the response Set-Cookie jar (x-evite-session, evtsession, csrftoken, x-evite-features). No browser bridge, no hand-copied cookie. Both vars must be set, or the resolver falls through. (Live.)
2. EVITE_SESSION_COOKIE — a raw cookie: header copied from a signed-in evite.com tab (or set in CI). Used verbatim. (Live.)
3. Fetchproxy bootstrap (fallback) — lift the session cookies (x-evite-session, evtsession, x-evite-features, csrftoken) from a signed-in evite.com browser tab via @fetchproxy/bootstrap, which needs the ContextMint Bridge browser extension (Chrome: load the chrome zip from the releases page unpacked. Safari isn't available yet — it will ship inside the ContextMint app, which has no public download — so use Chrome for now). ContextMint Bridge is the fetchproxy browser extension under its new name, from the same maintainer — fetchproxy's own README points to it. Its source is public at nullnet-app/contextmint-bridge: build it yourself, or check a release zip against the .sha256 file published beside it (shasum -a 256 -c contextmint-bridge-chrome-<version>.zip.sha256). Bootstrap runs once; every API call then goes out via plain Node fetch() with the cookies attached. Opt out with EVITE_DISABLE_FETCHPROXY=1. (Live.)

One tier is intentionally deferred (the resolver is shaped to slot it in):

• Fetchproxy as transport (bot-wall retry through the browser bridge) — a fallback only needed if plain fetch trips a wall; not observed during discovery.

The thirteen write tools (rsvp, add/update/remove-guest, send, send-message, broadcast, upload-photo, create/update/cancel/reinstate/duplicate event) ask you to confirm first (a prompt, or a preview + single-use confirmToken; see Confirmations). The single private client.write() helper attaches the CSRF token via one centralized header (CSRF_HEADER = X-CSRFToken; the csrftoken cookie rotates mid-session, so it's read fresh per request). Endpoints span three bases — REST /services/…, the legacy /ajax/event/{id}/… guest list, and the /tsunami/… messaging service — all live-verified; a couple of request bodies remain assumed (#3).

Development

npm install      # resolves @chrischall/mcp-utils from a local tarball (see issue #4)npm run buildnpm test

Docs & roadmap

• Design spec: docs/superpowers/specs/2026-05-31-evite-mcp-design.md
• Plan 1 (scaffold + spike): docs/superpowers/plans/2026-05-31-evite-mcp-scaffold-and-spike.md
• Plan 2 (auth + read tools): docs/superpowers/plans/2026-05-31-evite-mcp-auth-and-reads.md
• Internal API reference (verified from a live session): docs/EVITE-API.md

Open work: #3 — write endpoints + CSRF are now live-verified; only a couple of request bodies (send / send-message) remain assumed. #4 tracks publishing the shared lib. (Discovery #1, tier-1 email/password login #2, and the read tools are done.)

License

MIT