Skip to main content
Glama

Lemonvite

by com.lemonvite
OverviewDiscussionsAdmin

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
NameRequiredDescriptionDefault
guestsYesBatch 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_idYesLemonvite 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_creditsNoMaximum 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_consentNoSet 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
NameRequiredDescriptionDefault
addedYes
failedYes
resultsYes
guest_countYes
credits_usedYes
payment_requiredNoPresent when the batch needs phone allowance credits the call did not authorize. No guest was saved.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • 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"
+]
  2. Changed1 schema field changed
    • 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."
  3. Changed4 schema fields changed
    • 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"
+]
  4. Changed6 schema fields changed
    • 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."
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag destructive/openWorld/non-idempotent; the description goes far beyond them, disclosing draft vs published invite timing, SMS-consent prerequisites, guest_limit enforcement, the payment_required failure mode that saves none of the guests, per-guest independent results, and that purchased credits are shared with publishing so no further charge applies.

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?

Information is densely front-loaded with the when/when-not clause and batching instruction first. It is long and packs several distinct flows (consent, limits, credits, retry) into one paragraph, so it is efficient but borders on overloaded.

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?

Given four parameters, an output schema, and destructive annotations, the description covers everything an agent needs: prerequisites, failure semantics, credit flow, and follow-up tools. Return values are left to the output schema, as intended.

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 already 100%, so the baseline is 3; the description adds meaning beyond it by explaining that authorized_credits is a host-confirmed spend cap and that newly bought credits are shared with publishing, and by restating the min-contact rule for each guest.

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 and resource ('people actually added to the guest list of an existing Lemonvite invitation') and immediately differentiates from the near-neighbor scenario of brainstorming invitees. It also names the sibling to use for modifications (lemonvite_update_guests), so an agent can separate it from update/list/remove tools 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?

Explicit when (user wants people added) and when-not (brainstorming), plus concrete batching rules ('whole list in one call of up to 50 guests, not one call per guest'). It routes to specific alternatives: lemonvite_list_invitations to obtain event_id, lemonvite_start_checkout to buy credits, lemonvite_update_guests to fix existing guests.

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

All Lemonvite toolsInspect
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