Checkout Page

by com.checkoutpage

Overview Discussions Admin

create_coupon

Create a coupon for Checkout Page.

Use this when a merchant wants a discount code that customers can enter on eligible pages.

How page restrictions work:

Omit both pageIds and ticketTypeIds to create a coupon that is usable on all checkout pages and events.
Set pageIds to restrict the coupon to one or more specific pages.
ticketTypeIds are narrower than pageIds: they restrict the coupon to specific ticket types within an event.
If the page is an event, you must first restrict the coupon to that event by including the event page ID in pageIds, and only then can you narrow it to certain tickets from that event with ticketTypeIds.
Do not pass ticketTypeIds by themselves. Every ticket type must belong to one of the pageIds provided, or the request fails.

How discount types work:

amountOff is a fixed amount discount. It requires currency.
percentOff is a percentage discount applied to the eligible checkout total.
Set exactly one of amountOff or percentOff, never both.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	Yes	The coupon code a customer enters.
`label`	Yes	Internal name for the coupon.
`pageIds`	No	A list of pageIds that this coupon can be used within.
`currency`	No	Three-letter ISO code for the currency of the amountOff parameter. Required when `amountOff` is set, and not allowed when `percentOff` is set.
`duration`	Yes	How long the discount lasts: `once` applies to the first eligible payment, `repeating` applies for a fixed number of months, and `forever` applies until canceled or expired.
`redeemBy`	No	The ISO datetime that this coupon must be used before.
`amountOff`	No	A positive integer representing the amount to subtract from an invoice total (required if `percentOff` is not passed).
`percentOff`	No	A positive float larger than 0, and smaller or equal to 100, that represents the discount the coupon will apply (required if `amountOff` is not passed).
`ticketTypeIds`	No	List of ticket type IDs that this coupon can be used with. Ticket ticket ids must belong to a page specified in the `pageIds` array.
`maxRedemptions`	No	The total number of times this coupon can be redeemed across all customers. Doesn't limit a single customer from redeeming multiple times. Omit for unlimited redemptions.
`durationInMonths`	No	A positive integer representing the number of months the coupon applies for. Required when `duration === repeating`, and not allowed when `duration` is `once` or `forever`.
`appliesToSetupFee`	No	When enabled, applies this coupon discount to the setup fee.
`appliesToTicketFees`	No	When enabled, applies this coupon discount to ticket-level fees on event pages as well as the ticket prices. Defaults to false, which leaves ticket fees undiscounted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, non-open-world mutation, so the safety profile is covered. The description adds genuine behavioral rules beyond that: the pageIds/ticketTypeIds dependency and the hard failure ("or the request fails") when ticket types are passed without their parent page. It omits error behavior for duplicate codes and permission/auth requirements, keeping it out of the top band.

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 purpose and trigger are front-loaded, then two bolded sections group closely related constraints. For a 13-parameter tool every sentence carries distinct operational information with no repetition of schema text.

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?

An output schema exists, so return values need not be described, and annotations cover mutation safety. The description supplies the conditional logic needed to build a valid request, though it says nothing about duplicate-code handling or what the created coupon response contains.

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 would be 3, but the description adds real cross-parameter meaning: the hierarchical constraint that ticketTypeIds must be narrowed from pageIds, the event-page prerequisite, and the mutual exclusion of amountOff/percentOff. These are relational rules the schema only partially implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states a specific verb and resource ("Create a coupon for Checkout Page"), which is unambiguous and clearly distinct from update_coupon/list_coupons. It does not, however, explicitly name or rule out any sibling tool, so it falls short of the top band that requires active sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this when a merchant wants a discount code that customers can enter on eligible pages" gives a clear trigger condition for invoking the tool. There is no explicit when-not or alternative-tool guidance (e.g., when to update an existing coupon instead), so it stops short of a 5.

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

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