Skip to main content
Glama

Checkout Page

by com.checkoutpage
OverviewDiscussionsAdmin

create_event

Create a new event for selling tickets to an event.

Use this tool when a merchant wants to publish an event that sells tickets (conference, gala, workshop, class, etc.). An event has event details (at minimum a name; usually a start date/time and location) and one or more ticket groups, each containing one or more ticket types with a price (in the smallest currency unit, e.g. cents).

Examples:

  • Single free RSVP: one ticket group "General" with one $0 ticket "Admission".

  • Paid tiers: ticket types "Early Bird" 5000, "Standard" 7500, "VIP" 15000.

  • Capacity: set a ticket type quantity to cap how many can be sold.

Prices are integers in the smallest currency unit. Dates are ISO 8601.

For the page's design and customer-facing labels (including translations), set themeOverrides and hostedLayoutType; list_theme_properties lists what can be set. Set themeId (from list_themes) to use a theme.

After creation, return:

  • data.id: the event ID

  • data.name: the internal event name

  • data.hostedUrl: the live event URL

  • data.dashboardUrl: the dashboard edit URL

If the user is building or editing a website, call add_to_website next with pageId set to data.id and pageType: "event", and put the returned code in the site. Do not wait for the user to ask for this step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taxNo
feesNo
nameYesInternal page name used in your dashboard and API responses.
slugNoPage URL slug. For events and forms the slug defaults to the slugified version of your `title`. For checkouts the slug defaults to the slugified version of your `productData.title`.
titleNo
fieldsNoCustom checkout fields to create. When provided, at least one field must be an `email` element with `type` `email` and `required` `true`. When omitted, the page gets Name and Email address fields, plus a required billing Address on checkout and event pages. Forms get Name and Email address only.
localeNo
themeIdNoThe theme the page uses: one of your themes or a built-in one (see List themes). `themeOverrides` apply on top. Leave it out to use your store's default theme.
imageIdsNo
redirectNoIf enabled, redirects the customer to the specified URL before the page loads.
testmodeNoPuts the page in test mode. While it is on, every purchase on this page is a test purchase: no money is taken, the buyer still receives everything the page delivers, and the records are created with `livemode: false`. Turn it off to take real payments again.
descriptionNo
funnelStepsNoOrdered funnel configuration for this page. Supports intermediate checkout steps, one-click upsells, and confirmation behavior.
googleIndexNoAllow Google to index this page for search results. Defaults to `true`.
notifyEmailNoEmail addresses to send notifications to. Supports comma separated emails.
redirectUrlNoURL to redirect to after payment. Applies if `afterPaymentAction` is `redirect`.
eventDetailsNo
ticketGroupsNo
trackingCodesNoCustom tracking scripts to include on the page. Supports HTML `<script>` tags.
paymentMethodsNo
paymentOptionsNo
redirectPageIdNoID of the page (checkout, event or form) to redirect to after payment. Applies when `afterPaymentAction` is `checkout`.
themeOverridesNoThe page's design and labels, set on top of its theme and nested by theme property path: `tokens.colorPrimary` is sent as `{ "tokens": { "colorPrimary": { "light": "#1A73E8" } } }`. Keys you leave out keep their current value, and `null` resets a property, or everything under a key, to the theme default. Call `list_theme_properties` for the supported properties, their value formats and, where a property has a fixed one, its default.
invoiceSettingsNo
redirectUrlPathNoAdditional path parameters appended to the `redirectUrl`. Applies if `afterPaymentAction` is `redirect` and `redirectUrl` is set. [Learn more](https://checkoutpage.com/docs/articles/add-field-and-variant-data-to-redirect-url)
hostedLayoutTypeNo
redirectUrlQueryNoQuery parameters for the `redirectUrl`. Applies if `afterPaymentAction` is `redirect` and `redirectUrl` is set. [Learn more](https://checkoutpage.com/docs/articles/add-field-and-variant-data-to-redirect-url)
allowDynamicLabelNo
allowDynamicPriceNo
allowDynamicTitleNoAllow page title to be overridden via URL query parameters.
savePaymentMethodNo
afterPaymentActionNoBehavior after checkout. `confirmation` shows the confirmation page. `checkout` redirects to `redirectPageId`. `redirect` sends the customer to `redirectUrl`. Defaults to `confirmation`.
checkoutAbandonmentNo
showCouponCodeFieldNo
sendEmailConfirmationNoSend an email confirmation to the customer. Defaults to `true`.
redirectUrlInsideEmbedNoIf the page is embedded, redirect the customer within the embed instead of redirecting the main browser window. Defaults to `false`.
allowDynamicDescriptionNoAllow page description to be overridden via URL query parameters.
allowDynamicRedirectUrlNo
sendPaymentNotificationNoSend payment/submission notification emails to the store owner.
showCouponCodeFieldTypeNo
closePopupOnClickOutsideNoWhether a popup embed closes when clicking outside the container. Defaults to `false`.
confirmationEmailMessageNoCustom confirmation email message. Accepts HTML or plain text.
confirmationEmailSubjectNoCustom confirmation email subject.
confirmationCheckoutTitleNoConfirmation title.
confirmationEmailShowLogoNoShow store logo in confirmation email.
showConfirmationEventNameNo
customizeEmailConfirmationNoUse a custom email confirmation template. If enabled, provide `confirmationEmailSubject` and `confirmationEmailMessage`.
confirmationCheckoutMessageNoConfirmation message. Accepts HTML or plaintext.
showConfirmationEventAddOnsNo
allowDynamicPreselectedPriceNo
showConfirmationEventTicketsNo
customizeCheckoutConfirmationNoIf set to true `confirmationCheckoutMessage` and `confirmationCheckoutTitle` will be displayed on the confirmation page. Defaults to `false`.
showConfirmationAddToCalendarNo
showConfirmationEventDateTimeNo
showConfirmationEventLocationNo
confirmationEmailShowStoreNameNoShow store name in confirmation email.
allowDynamicDiscountedFromPriceNo
showConfirmationEventMeetingLinkNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds real behavioral context beyond that: the structure (event details + ticket groups + ticket types), the pricing unit convention, and the exact return fields (id, name, hostedUrl, dashboardUrl). It doesn't discuss auth, limits, or side effects of failure, so not a 5.

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 purpose, then usage, then examples, then field/return guidance. The three short examples are efficient illustrations. A bit verbose in the design-labels paragraph, but every sentence carries guidance.

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

Completeness4/5

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

Covers the core flow of creating an event, naming key inputs, and enumerating return fields, so an agent can act end-to-end. Given the enormous 58-param surface, some advanced options (funnels, payment options, tax) are left to the schema, which is acceptable since output schema also exists.

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

Parameters3/5

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

Schema coverage is 52%, and the description targets the most important pieces anyway: prices as integers in smallest currency unit, ISO 8601 dates, themeOverrides/hostedLayoutType usage, and themeId via list_themes. But for a 58-parameter tool with 52% coverage, the description leaves many parameters (fees, funnelSteps, paymentOptions, etc.) undocumented in prose.

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 ('Create a new event for selling tickets') and scopes it precisely. It distinguishes itself from siblings like create_checkout_page by emphasizing ticket-selling events and even names related tools (list_themes, add_to_website) for follow-up work.

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 ('when a merchant wants to publish an event that sells tickets') with concrete examples (single free RSVP, paid tiers, capacity). It also prescribes a next action ('call add_to_website next... Do not wait for the user to ask'), which is unusually actionable guidance.

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

All Checkout Page 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