Skip to main content
Glama

Generate an invitation design

lemonvite_generate_design
Destructive

Use this when the user wants Lemonvite's design engine to create the invitation artwork — because this assistant cannot produce images itself, or because the user asked for a Lemonvite design. Describe the look in design_brief (theme, colours, mood, motifs); the event date, time and venue are lettered onto the design automatically unless include_event_details is false. A reference_image from the conversation guides the engine's style. Each call spends one of the host's design generations (new accounts start with 5; every purchased publish credit adds 5) and REPLACES the current artwork (the previous design stays in the event's design history on the website), so confirm with the user before calling it. If this assistant already made an image in the conversation, attach it with invitation_image on lemonvite_update_invitation instead. Never call it merely because designs or themes are being discussed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idYes
design_briefNoThe host's art direction in their own words: theme, colours, mood, motifs, style. Omit for a default design suited to the event type.
reference_imageNoAn image already present in this conversation for the design engine to draw on (style, subject, palette). JPEG, PNG or WebP. It guides the design and is not stored as the invitation artwork.
include_event_detailsNoLetter the date, time and venue onto the design (default true).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
invitationYes
generations_remainingYesDesign generations left on the connected account after this call. New accounts start with 5; every purchased publish credit adds 5.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The description goes beyond annotations by disclosing that each call consumes a design generation credit (starting at 5, +5 per publish credit), that it REPLACES the current artwork (with the old one preserved in history), and that user confirmation is required before calling. This reinforces destructiveHint=true and adds quota and confirmation context.

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

Conciseness5/5

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

The description is information-dense with no filler. It front-loads the core purpose and usage conditions, then systematically covers parameters, side effects, quota, and the alternative. Every sentence contributes actionable guidance, and it is well-structured for an agent to parse.

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?

For a destructive, quota-consuming mutation with an output schema, the description covers all essential aspects: when to use, parameter semantics, automatic behaviors, side effects, cost, confirmation requirement, and routing to an alternative. The agent has everything needed to call it correctly and safely.

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?

The description enriches the schema: it explains that design_brief carries theme/colours/mood/motifs, that event details are lettered automatically unless include_event_details is false, and that reference_image guides style but is not stored as artwork. These clarifications go well beyond the schema descriptions, significantly aiding correct invocation.

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?

The description clearly states the tool's purpose: it uses Lemonvite's design engine to create invitation artwork. It explicitly differentiates from siblings by noting when to use it (when the assistant cannot produce images or when the user asks for a Lemonvite design) and names an alternative (lemonvite_update_invitation) for attaching existing images.

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?

Provides explicit usage conditions: use it when the user wants the design engine to create artwork, and never merely for design discussion. It also states a clear alternative (lemonvite_update_invitation) when an image already exists in the conversation, giving the agent unambiguous routing.

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