Skip to main content
Glama

Edit the invitation design

lemonvite_edit_design
Destructive

Use this when the user wants a change to the invitation's CURRENT artwork rather than a new design — "make the sky a sunset", "change the balloons to gold", "remove the banner at the bottom". Lemonvite's design engine applies the request to the existing artwork and leaves everything else as it is. Put the user's request in edit_request in their own words; do not rewrite it into a design brief. Each call spends one of the host's design generations (same as lemonvite_generate_design) and REPLACES the current artwork (the previous version stays in the event's design history on the website), so confirm with the user before calling it. The invitation must already have artwork that is not a GIF and has no text or image layers added in the web editor (those are edited on the website); to create artwork from scratch use lemonvite_generate_design, and to attach an image this assistant made use invitation_image on lemonvite_update_invitation. Get event_id from lemonvite_list_invitations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
edit_requestYesThe change the user wants, in their own words (what to add, remove, recolour or move). Everything the request does not mention stays as it is.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
invitationYes
generations_remainingYesDesign generations left on the connected account after this call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / generations_remaining / description
      Previous value: -"Design generations left on the connected account after this call. New accounts start with 5; every purchased account credit adds 5."New value: +"Design generations left on the connected account after this call."
    • changedOutput schema / properties / invitation / properties / payment_status / description
      Previous value: -"paid = this event is already covered; credit_available = balance covers all required publishing and phone credits; payment_required = start_checkout first; not_applicable = cancelled, do not buy credits or publish. Always reflects the PRIMARY host's account — the one publishing charges."New value: +"paid = this event is already covered; credit_available = balance covers all required publishing and phone credits; payment_required = the account's credits do not cover publishing; not_applicable = cancelled, cannot be published. Always reflects the PRIMARY host's account — the one whose credits publishing uses."
    • changedOutput schema / properties / invitation / properties / phone_guest_allowance / description
      Previous value: -"Included or already purchased phone guests; null = no phone cap."New value: +"Phone guests this event already allows; null = no phone cap."
  2. Changed11 schema fields changed
    • changedOutput schema / properties / generations_remaining / description
      Previous value: -"Design generations left on the connected account after this call. New accounts start with 5; every purchased publish credit adds 5."New value: +"Design generations left on the connected account after this call. New accounts start with 5; every purchased account credit adds 5."
    • changedOutput schema / properties / invitation / properties / can_publish / description
      Previous value: -"True when this account is the event's primary host — the only account that can publish it or pay for it. Co-hosts can edit the invitation and manage guests, but must ask the primary host to publish."New value: +"True when this account is the event's primary host and the event is not cancelled. Co-hosts can edit the invitation and manage guests, but must ask the primary host to publish."
    • addedOutput schema / properties / invitation / properties / guest_limit
      Added value: +{
      +  "description": "Total cap; only support can raise it. null = verified host.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / invitation / properties / payment_status / description
      Previous value: -"paid = this event is already covered; credit_available = publish will consume an existing credit; payment_required = start_checkout first. Always reflects the PRIMARY host's account — the one publishing charges."New value: +"paid = this event is already covered; credit_available = balance covers all required publishing and phone credits; payment_required = start_checkout first; not_applicable = cancelled, do not buy credits or publish. Always reflects the PRIMARY host's account — the one publishing charges."
    • changedOutput schema / properties / invitation / properties / payment_status / enum
      Previous value: -[
      -  "paid",
      -  "credit_available",
      -  "payment_required"
      -]New value: +[
      +  "paid",
      +  "credit_available",
      +  "payment_required",
      +  "not_applicable"
      +]
    • addedOutput schema / properties / invitation / properties / phone_batch_size
      Added value: +{
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / invitation / properties / phone_guest_allowance
      Added value: +{
      +  "description": "Included or already purchased phone guests; null = no phone cap.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / invitation / properties / phone_guest_count
      Added value: +{
      +  "type": "number"
      +}
    • addedOutput schema / properties / invitation / properties / publishing_price
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": false,
      +      "properties": {
      +        "amount_due": {
      +          "type": "number"
      +        },
      +        "credits_to_buy": {
      +          "type": "number"
      +        },
      +        "existing_credits": {
      +          "type": "number"
      +        },
      +        "phone_batch_count": {
      +          "type": "number"
      +        },
      +        "phone_batch_price": {
      +          "type": "number"
      +        },
      +        "publish_price": {
      +          "type": "number"
      +        },
      +        "total_price": {
      +          "type": "number"
      +        }
      +      },
      +      "required": [
      +        "publish_price",
      +        "phone_batch_count",
      +        "phone_batch_price",
      +        "total_price",
      +        "existing_credits",
      +        "credits_to_buy",
      +        "amount_due"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / invitation / properties / required_credits
      Added value: +{
      +  "description": "Publishing plus phone batches. Review with the host before authorizing this many credits.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / invitation / required
      Previous value: -[
      -  "event_id",
      -  "publish_status",
      -  "payment_status",
      -  "can_publish",
      -  "title",
      -  "event_type",
      -  "description",
      -  "start_datetime",
      -  "end_datetime",
      -  "timezone",
      -  "location",
      -  "host_name",
      -  "rsvp_deadline",
      -  "image_url",
      -  "has_invitation_image",
      -  "price_display",
      -  "guest_count",
      -  "rsvp_summary",
      -  "public_rsvp_url",
      -  "manage_url",
      -  "custom_fields",
      -  "guest_settings"
      -]New value: +[
      +  "event_id",
      +  "publish_status",
      +  "payment_status",
      +  "can_publish",
      +  "title",
      +  "event_type",
      +  "description",
      +  "start_datetime",
      +  "end_datetime",
      +  "timezone",
      +  "location",
      +  "host_name",
      +  "rsvp_deadline",
      +  "image_url",
      +  "has_invitation_image",
      +  "price_display",
      +  "guest_count",
      +  "phone_guest_count",
      +  "guest_limit",
      +  "phone_guest_allowance",
      +  "phone_batch_size",
      +  "required_credits",
      +  "publishing_price",
      +  "rsvp_summary",
      +  "public_rsvp_url",
      +  "manage_url",
      +  "custom_fields",
      +  "guest_settings"
      +]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=false; the description goes well beyond them by disclosing the cost (one design generation), the destructive effect (REPLACES current artwork, prior version retained in history), and a required confirmation step. It also states eligibility limits (non-GIF, no web-editor layers) that the annotations cannot express.

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?

The design/versus-edit distinction is front-loaded and every clause carries operational weight (cost, replacement, confirmation, preconditions, alternatives). It is dense and long for a two-parameter tool, but there is no filler or repetition.

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. The description covers side effects, cost, confirmation requirement, preconditions, and routing to three alternative tools, leaving nothing an agent needs before calling it.

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 baseline is 3, but the description adds genuine semantics: edit_request must be the user's own words and must NOT be rewritten into a design brief, and unmentioned aspects stay unchanged. Silence on event_id is acceptable since the schema already forbids confusing it with invitation_id or RSVP URL.

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 (edit the invitation's existing artwork) and immediately contrasts it with the sibling lemonvite_generate_design. The examples ('make the sky a sunset') pin down the resource boundary between editing and creating, so the agent can distinguish it from 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?

Explicit when-to-use ('user wants a change to CURRENT artwork rather than a new design'), explicit when-not ('to create artwork from scratch use lemonvite_generate_design'), and a third routed case ('to attach an image this assistant made use invitation_image on lemonvite_update_invitation'). Preconditions are also spelled out (existing non-GIF artwork, no text/image layers).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources