evite-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EVITE_EMAIL | No | Evite account email for tier-1 authentication (used together with EVITE_PASSWORD). | |
| EVITE_PASSWORD | No | Evite account password for tier-1 authentication (used together with EVITE_EMAIL). | |
| EVITE_SESSION_COOKIE | No | Raw cookie header copied from a signed-in evite.com browser session (tier-2 authentication). | |
| EVITE_DISABLE_FETCHPROXY | No | Set to '1' to disable the fetchproxy bootstrap fallback authentication. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| evite_healthcheckA | Report evite-mcp status and the resolved auth mode. |
| evite_list_eventsA | List your Evite events (GET /services/events/v1/). Returns events plus a totals breakdown. filterBy=others returns events where you are a guest. |
| evite_get_eventA | Get a single Evite event detail (GET /services/event/v1/{id}): event, settings, location, and more. |
| evite_list_templatesA | List invitation templates from a gallery category — use this to find the |
| evite_list_guestsB | List the guests for an Evite event (GET /services/event/v1/{id}/guests/): name, RSVP response, head counts, delivery status, and more. |
| evite_rsvp_summaryA | Get the RSVP summary for an Evite event (yes/no/maybe/noReply plus adult/kid head counts). Derived from the event guests endpoint. |
| evite_list_messagesA | List the messages on an Evite event's Messages tab (GET /services/event/v1/{id}/posts/). |
| evite_rsvpA | RSVP for a guest on an Evite event. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_send_messageA | Send a private message to one Evite event guest. This really notifies the guest. Sent as the event host (Evite delivers per-guest chat over Firebase, not REST), so only a host can use it. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_broadcastA | Broadcast a message to whole RSVP segments of an Evite event at once (e.g. everyone who replied yes/maybe). This really emails every guest in those segments. If a call fails or times out it may still have gone out — check evite_list_messages before calling again. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_upload_photoA | Upload a local image to an Evite event's shared photo gallery. This really adds the photo to the event album. Needs your guest_id on the event (from evite_list_guests). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_create_eventA | Create an Evite event (as a draft). Requires title, start_datetime, and template_name. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Evite answers a create with a 500 even when the draft IS created; this tool handles that by re-listing your drafts, and returns created:true with the eventId, or created:"unknown" when it cannot confirm — never call it again for the same event; check the drafts instead. |
| evite_update_eventA | Edit an existing Evite event (only the fields you pass change). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_add_guestA | Add guests to an event's draft (un-sent) guest list. Nothing is emailed until you evite_send. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). NB: guests only persist on a finalized (sent/sending) event, not a bare new draft. |
| evite_update_guestA | Edit a draft (un-sent) guest's name/email/phone on an Evite event. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_remove_guestA | Remove a draft (un-sent) guest from an Evite event. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_sendA | Send the invitation to the ready-to-send (draft) guests of an event ("Send now"). THIS EMAILS GUESTS. If a call fails or times out it may still have sent — check evite_list_guests (delivery status) before calling again. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_cancel_eventA | Cancel an Evite event (also used to delete a draft). DESTRUCTIVE — may send a cancellation notice to guests; reversible with evite_reinstate_event. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_reinstate_eventA | Reinstate a previously-cancelled Evite event (the inverse of evite_cancel_event). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| evite_duplicate_eventA | Duplicate an Evite event into a fresh draft (the "Duplicate event" action). Returns the new draft event id. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Each tool targets a distinct resource and action, with no true duplicates. Potential overlaps like evite_send vs evite_send_message vs evite_broadcast are clearly separated by scope (invitations, private guest chat, segment broadcast).
All tools use the evite_ prefix and snake_case, giving a consistent, recognizable style. Most follow a verb_noun pattern, though a few are verb-only (evite_send, evite_rsvp, evite_broadcast) or noun-only (evite_healthcheck), which are minor deviations.
20 tools is on the heavy side for an MCP integration and falls into the borderline 16-25 range. Most map to distinct Evite operations, but a few (e.g., evite_rsvp_summary derived from guest data) could potentially be consolidated.
The core event and guest lifecycle is well covered: create, update, duplicate, cancel, reinstate, list, guest management, RSVP, messaging, and photo upload. Minor gaps remain, such as photo listing/removal, event search, and richer guest detail operations.