Lemonvite

Add guests

lemonvite_add_guests

Destructive

Use this when the user wants people actually added to the guest list of an existing Lemonvite invitation; do not use it while the user is only brainstorming whom to invite. Send the whole list in one call of up to 50 guests, not one call per guest; each needs at least a name, email or phone. Get event_id from lemonvite_list_invitations. On a published invitation, new guests with an email or phone are invited immediately; on a draft, invitations go out at publish. Adding a guest by phone requires host_confirms_sms_consent=true, meaning the host confirmed these people agreed to receive SMS about this event. The total guest_limit applies to drafts too; only support can raise it. Phone guests beyond the phone allowance are priced in saved batches at publishing on a draft; on a published invitation they return payment_required for the whole call, and none of its guests is saved. Explain the credit cost and the new phone allowance. If needed: Buy the creditsToBuy shortfall with lemonvite_start_checkout without event_id. Then retry only the unsaved guests with authorized_credits after explicit host confirmation. Those credits are shared with publishing; these guests add no further publishing charge. Each guest gets its own result; an invalid or already-invited guest fails alone without stopping the others. To fix an existing guest use lemonvite_update_guests.

Input Schema

TableJSON Schema

Name	Required	Description
`guests`	Yes	Batch of 1–50 guests to add. Each needs at least a name, email, or phone. Guests with contact details are invited immediately if the event is published.
`event_id`	Yes	Lemonvite event_id returned by lemonvite_create_invitation or lemonvite_list_invitations. Identifies the event to act on; not a guest invitation_id or RSVP URL.
`authorized_credits`	No	Maximum shared account credits the host explicitly agreed to spend across this entire request. Default 0: return payment_required without spending. Explain the credits used and the increased phone allowance, and obtain confirmation before setting this.
`host_confirms_sms_consent`	No	Set true only when the host confirms the guests agreed to receive SMS about this event. Required when adding guests with phone numbers.

Output Schema

TableJSON Schema

Name	Required	Description
`added`	Yes
`failed`	Yes
`results`	Yes
`guest_count`	Yes
`credits_used`	Yes
`payment_required`	No	Present when the batch needs phone allowance credits the call did not authorize. No guest was saved.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 28, 2026

addedOutput schema / properties / payment_required

Added value: +{
+  "additionalProperties": false,
+  "description": "Present when the batch needs phone allowance credits the call did not authorize. No guest was saved.",
+  "properties": {
+    "creditsToBuy": {
+      "type": "number"
+    },
+    "maxInvitations": {
+      "type": "number"
+    },
+    "maxPhoneInvitations": {
+      "type": "number"
+    },
+    "requiredCredits": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "requiredCredits",
+    "creditsToBuy",
+    "maxPhoneInvitations",
+    "maxInvitations"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / results / items / properties / contact_id
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / results / items / properties / payment_required

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "creditsToBuy": {
-      "type": "number"
-    },
-    "maxInvitations": {
-      "type": "number"
-    },
-    "maxPhoneInvitations": {
-      "type": "number"
-    },
-    "requiredCredits": {
-      "type": "number"
-    }
-  },
-  "required": [
-    "requiredCredits",
-    "creditsToBuy",
-    "maxPhoneInvitations",
-    "maxInvitations"
-  ],
-  "type": "object"
-}

changedOutput schema / properties / results / items / required

Previous value: -[
-  "guest",
-  "ok"
-]New value: +[
+  "ok"
+]

Changed1 schema field changedSep 25, 2026

changedInput schema / properties / authorized_credits / description

Previous value: -"Maximum shared account credits the host explicitly agreed to spend across this entire request. Default 0: return payment_required without spending. Explain the cost and increased phone allowance and obtain confirmation before setting this."New value: +"Maximum shared account credits the host explicitly agreed to spend across this entire request. Default 0: return payment_required without spending. Explain the credits used and the increased phone allowance, and obtain confirmation before setting this."

Changed4 schema fields changedSep 21, 2026

addedInput schema / properties / authorized_credits

Added value: +{
+  "default": 0,
+  "description": "Maximum shared account credits the host explicitly agreed to spend across this entire request. Default 0: return payment_required without spending. Explain the cost and increased phone allowance and obtain confirmation before setting this.",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / credits_used
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / results / items / properties / payment_required

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "creditsToBuy": {
+      "type": "number"
+    },
+    "maxInvitations": {
+      "type": "number"
+    },
+    "maxPhoneInvitations": {
+      "type": "number"
+    },
+    "requiredCredits": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "requiredCredits",
+    "creditsToBuy",
+    "maxPhoneInvitations",
+    "maxInvitations"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "added",
-  "failed",
-  "guest_count",
-  "results"
-]New value: +[
+  "added",
+  "failed",
+  "credits_used",
+  "guest_count",
+  "results"
+]

Changed6 schema fields changedSep 10, 2026

addedInput schema / properties / event_id / description

Added value: +"Lemonvite event_id returned by lemonvite_create_invitation or lemonvite_list_invitations. Identifies the event to act on; not a guest invitation_id or RSVP URL."

addedInput schema / properties / guests / description

Added value: +"Batch of 1–50 guests to add. Each needs at least a name, email, or phone. Guests with contact details are invited immediately if the event is published."

addedInput schema / properties / guests / items / properties / email / description

Added value: +"Guest email address, e.g. alex@example.com, up to 320 characters."

addedInput schema / properties / guests / items / properties / name / description
```
Added value: +"Guest display name, up to 200 characters."
```

changedInput schema / properties / guests / items / properties / phone / description

Previous value: -"E.164 preferred, e.g. +15551234567"New value: +"Guest phone number, up to 32 characters; E.164 preferred, e.g. +15551234567. Requires host_confirms_sms_consent=true."

addedInput schema / properties / host_confirms_sms_consent / description

Added value: +"Set true only when the host confirms the guests agreed to receive SMS about this event. Required when adding guests with phone numbers."

First observedSep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare a write/destructive/non-idempotent/open-world profile, and the description substantially enriches it: immediate invitation on published vs deferred to publish on draft, SMS consent requirement, guest_limit immutability, phone pricing behavior, payment_required short-circuit that saves no guests, per-guest isolation of failures, and credit sharing with publishing. This goes well beyond what annotations convey.

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?

Long but front-loaded with purpose and batch rule; nearly every sentence carries operational weight given payment, SMS-consent, and batch complexity. It reads as one dense block rather than scannable sections, which is the only weakness.

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?

With an output schema present, return values need not be described, and the description still covers the branching behaviors (published vs draft, consent, credits, per-guest results) an agent needs to call this correctly. Complete for a high-complexity write tool.

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

Parameters4/5

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

Schema coverage is 100%, so the schema carries parameter definitions; the description nonetheless adds workflow meaning beyond it, explaining the authorized_credits shortfall/buy-then-retry loop and the semantic weight of host_confirms_sms_consent. Marginal but real added value over the schema.

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?

States a specific verb+resource ('people actually added to the guest list of an existing Lemonvite invitation') and explicitly fences off the nearest sibling behavior (brainstorming) and the update path (lemonvite_update_guests for fixing existing guests). An agent can distinguish this from list/add/update/invite siblings without opening schemas.

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?

Gives explicit when-to-use, when-not ('do not use it while the user is only brainstorming whom to invite'), batch guidance ('send the whole list in one call of up to 50 guests, not one call per guest'), and names alternatives (lemonvite_update_guests, lemonvite_start_checkout). Nothing is left to inference.

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

All Lemonvite tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?