evite-mcp

evite_upload_photo

Destructive

Upload a photo to an Evite event's shared gallery using event and guest IDs, via a local file path, inline base64 image, or hosted upload-slot blob key.

Instructions

Upload a photo 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). Pass the image as exactly one of: path (a file in EVITE_UPLOAD_DIR — local installs only), inline (base64 — small files), or blob_key. On the hosted connector, use the slot flow: call evite_upload_slots, PUT the file to the uploadUrl with its curl command, then pass the returned blobKey here as blob_key. JPEG/PNG/GIF/WebP/HEIC, max 20 MB. 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).

Input Schema

Name	Required	Description
`path`	No	LOCAL INSTALLS ONLY. Path to the image file, inside the upload directory (EVITE_UPLOAD_DIR, default ~/Downloads/evite-mcp; a relative path is resolved there, a leading ~ is expanded; hidden files are refused). Refused on the hosted connector — use blob_key (via evite_upload_slots) or inline there.
`inline`	No	The image itself, base64-encoded. Works everywhere; best for a small photo.
`blob_key`	No	The blobKey of an upload slot from evite_upload_slots, after the file was PUT to its uploadUrl. The hosted way to send a photo of any size. Deleted once Evite accepts the photo; kept if the upload fails, so a retry can reuse it.
`event_id`	Yes	Evite event id (event_id from evite_list_events).
`guest_id`	Yes	Your guest id on the event (guestId from evite_list_guests — your own row, guestType host/cohost/guest).
`mimetype`	No	Override the image mimetype (otherwise inferred from the filename). Must match the file contents.
`confirmToken`	No	ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.5.0Nov 9, 2026

addedInput schema / properties / blob_key

Added value: +{
+  "description": "The blobKey of an upload slot from evite_upload_slots, after the file was PUT to its uploadUrl. The hosted way to send a photo of any size. Deleted once Evite accepts the photo; kept if the upload fails, so a retry can reuse it.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / inline

Added value: +{
+  "description": "The image itself, base64-encoded. Works everywhere; best for a small photo.",
+  "properties": {
+    "content_base64": {
+      "description": "The image bytes, standard base64 (a \"data:image/…;base64,\" prefix and line breaks are tolerated).",
+      "minLength": 1,
+      "type": "string"
+    },
+    "filename": {
+      "description": "Filename to store the photo under — a bare name with an image extension, e.g. \"photo.jpg\".",
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "filename",
+    "content_base64"
+  ],
+  "type": "object"
+}

changedInput schema / properties / mimetype / description

Previous value: -"Override the image mimetype (otherwise inferred from the file). Must match the file contents."New value: +"Override the image mimetype (otherwise inferred from the filename). Must match the file contents."

changedInput schema / properties / path / description

Previous value: -"Path to the local image file to upload, inside the upload directory (EVITE_UPLOAD_DIR, default ~/Downloads/evite-mcp; a relative path is resolved there, a leading ~ is expanded; hidden files are refused). JPEG/PNG/GIF/WebP/HEIC, max 20 MB."New value: +"LOCAL INSTALLS ONLY. Path to the image file, inside the upload directory (EVITE_UPLOAD_DIR, default ~/Downloads/evite-mcp; a relative path is resolved there, a leading ~ is expanded; hidden files are refused). Refused on the hosted connector — use blob_key (via evite_upload_slots) or inline there."

changedInput schema / required

Previous value: -[
-  "event_id",
-  "guest_id",
-  "path"
-]New value: +[
+  "event_id",
+  "guest_id"
+]

Changed1 schema field changedv1.3.6Oct 17, 2026

changedInput schema / properties / path / description

Previous value: -"Path to the local image file to upload (a leading ~ is expanded). JPEG/PNG/GIF/WebP/HEIC, max 20 MB."New value: +"Path to the local image file to upload, inside the upload directory (EVITE_UPLOAD_DIR, default ~/Downloads/evite-mcp; a relative path is resolved there, a leading ~ is expanded; hidden files are refused). JPEG/PNG/GIF/WebP/HEIC, max 20 MB."

Changed2 schema fields changedv1.3.0Sep 25, 2026

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true to proceed. Without this, the tool returns a preview.",
-  "type": "boolean"
-}

addedInput schema / properties / confirmToken

Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}

Changed2 schema fields changedv1.1.3Sep 24, 2026

changedInput schema / properties / mimetype / description

Previous value: -"Override the image mimetype (otherwise inferred from the file extension)."New value: +"Override the image mimetype (otherwise inferred from the file). Must match the file contents."

addedInput schema / properties / mimetype / enum

Added value: +[
+  "image/jpeg",
+  "image/png",
+  "image/gif",
+  "image/webp",
+  "image/heic",
+  "image/heif"
+]

Changed1 schema field changedv1.0.0Sep 19, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv0.5.0Aug 3, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses the confirmation requirement, the two-phase confirmToken fallback and MCP_CONFIRM_MODE dependency, accepted formats and the 20 MB ceiling, and the blob_key lifecycle (deleted on success, retained on failure for retry). These are real behavioral consequences an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then prerequisites, then transport options, then limits, then confirmation — a logical ordering with no filler. It is dense and longer than most, with heavy parentheticals, but nearly every clause carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with no output schema and a complex two-phase confirmation path, yet the description covers inputs, size/format limits, hosted-vs-local behavior, and exactly what happens on success and failure. An agent has enough to call it correctly without opening any sibling schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds constraints the schema cannot express: 'exactly one of' path/inline/blob_key, which prevents an agent from passing several at once. It also ties guest_id to its source (evite_list_guests) and confirmToken to a specific phase-1 response, adding cross-parameter semantics beyond the field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Upload a photo to an Evite event's shared photo gallery.' The follow-up sentence clarifies it truly writes to the event album, and the slot-flow sentence distinguishes it from the sibling evite_upload_slots, which only provisions an upload URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the three mutually exclusive ways to send the image and the conditions that select each: path is 'local installs only', inline is for 'small files', blob_key is 'the hosted way to send a photo of any size.' It also names the prerequisite tool (evite_list_guests for guest_id) and the alternative evite_upload_slots flow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

evite_upload_photo

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools