Skip to main content
Glama

walletmcppass: Apple Wallet passes

Create Apple Wallet pass

create_wallet_pass

Create a signed Apple Wallet pass (.pkpass) and return a link to download it.

Builds one pass in one of the five Wallet styles -- boardingPass, eventTicket, coupon,
storeCard or generic -- from the text fields, colors, barcode and optional PNG images
given below, signs it with this service's Apple Pass Type ID certificate, and returns an
https download_url valid for 1 hour. Opening the link on an iPhone shows "Add to
Apple Wallet". Passes install on any iOS version; the iOS 26/27 layouts fall back to the
classic style on older iPhones.

Barcodes: QR, PDF417, Aztec and Code128 on every iOS version; Code39, Codabar, EAN13 and
ITF on iOS 27+. The barcode encodes exactly barcode_message. Gate and till scanners read
that data, so a copy of an existing boarding pass, ticket or loyalty card only scans if
barcode_message is the original barcode's content (airline boarding passes are usually
PDF417 or Aztec, holding an IATA BCBP string such as "M1DOE/JANE ..."). This tool does not issue
tickets, check anyone in, or contact airlines or venues.

The link must be opened in Safari on the iPhone: Wallet adds a pass from Safari, but not
from a .pkpass file handed over by another app. Google Wallet on Android also imports these
files. Not supported: NFC passes.

With updatable=True the pass can be changed later with update_wallet_pass, and copies
already in Wallet refresh themselves. Its contents are then stored on this server for
updatable_hours (1 hour by default, at most 30 days), then deleted.

Returns {download_url, expires_in_seconds, serial_number, pass_type_identifier}, plus
edit_token and updatable_until when updatable=True.

Pricing: a call is one create or one update. Free for 30 calls a day per caller IP, while a
shared pool of 500 free calls a day lasts; failed calls count too, and counts reset at 00:00 UTC.
Past either limit, a call costs $0.01 in USDC on Base, paid with x402; the refusal carries the
payment requirements, and a paid result includes the payment receipt. Payment is settled only
after the pass is built, so a failed build is never charged.

Args:
    style: one of "boardingPass", "eventTicket", "coupon", "generic", "storeCard".
    organization_name: shown as the pass issuer.
    description: accessibility description (required by Wallet, not usually shown).
    logo_text: text shown next to the logo image.
    transit_type: only for style="boardingPass" -- "Air", "Boat", "Bus", "Generic", or "Train" (default "Air").
    barcode_message: raw text/data encoded into the barcode. Omit for no barcode.
    barcode_format: a format name or an ordered list of them; each becomes a barcode with the
        same message, and Wallet shows the first one the device supports. Nothing is added that
        you don't list. Formats: "QR" (default), "PDF417", "Aztec", "Code128" (all iOS versions),
        and iOS 27+ only: "Code39", "Codabar", "EAN13", "ITF" -- older iPhones skip these, so
        e.g. ["EAN13", "Code128"] shows EAN13 on iOS 27 and Code128 before it. EAN13 needs
        12-13 digits, ITF an even number of digits, Code39 uppercase letters/digits.
    barcode_alt_text: human-readable text shown under the barcode (e.g. the card number).
    background_color / foreground_color / label_color: hex colors, e.g. "#1a1a19".
    relevant_date / expiration_date: ISO 8601 timestamps.
    locations: up to 10 places where the pass appears on the lock screen when the iPhone is
        nearby, each {"latitude": float, "longitude": float, "altitude": optional float,
        "relevantText": optional str shown on the lock screen, e.g. "Your gym card"}. Look up
        the coordinates of the actual branch, not just the brand. For boardingPass and
        eventTicket the pass is relevant near a location around relevant_date if one is set;
        the other styles use location alone. Wallet only shows a pass within its own default
        radius of a location, which is small for store cards and coupons.
    max_distance: meters; shrinks the default radius around every location (Wallet uses the
        smaller of the two, so it cannot enlarge it). Requires locations.
    voided: mark the pass voided/used (shows a "VOID" stamp).
    primary_fields / secondary_fields / auxiliary_fields / header_fields / back_fields:
        lists of {"key": optional str, "label": optional str, "value": str, "changeMessage":
        optional str} shown on the pass. changeMessage only matters on updatable passes: when
        an update changes that field's value, the iPhone shows it as a lock-screen notification,
        with %@ replaced by the new value (e.g. "You now have %@ points"); without %@ Wallet
        shows a generic message. Updates match fields by key, so give fields that will change
        an explicit key (auto keys are by position).
    serial_number: unique id for this pass; auto-generated if omitted.
    icon_color / icon_text: control the auto-generated icon (a colored square with initials)
        when icon_png_b64 is not supplied.
    logo_color: color of the auto-generated logo image, a wordmark of logo_text (or
        organization_name) drawn on a transparent background over background_color. Defaults
        to icon_color. Wallet also renders logo_text as text beside the logo image, so the
        generated wordmark repeats it -- set generate_logo=False to show only the text.
    icon_png_b64 / logo_png_b64: PNG to use instead of auto-generated art.
    Every *_png_b64 parameter takes either base64 PNG data or an https:// URL of an image
    (PNG, JPEG, WebP or GIF, up to 5 MB; non-PNG is converted to PNG). The URL is fetched once,
    when the pass is built.
    generate_logo: set False to include no auto-generated logo or primary logo at all (both are
        optional in Wallet; a supplied logo_png_b64/primary_logo_png_b64 is still used).
    poster: (iOS 27+) render as Apple's new full-bleed "Poster Generic" layout -- large background
        image, header field, up to 4 primary fields, up to 2 footer_fields, and a square QR code.
        Only for style "generic", "storeCard" or "coupon"; that style is kept as the fallback
        older iPhones display (secondary/auxiliary fields only show on the fallback). Good for
        memberships, loyalty cards and gift cards.
    footer_fields: up to 2 fields along the bottom of a poster pass (requires poster=True).
    background_png_b64: base64 PNG poster background, ideally 1035x1515 px (345x505pt @3x);
        a gradient in background_color is generated if omitted. Only used when poster=True.
    featured_actions: (iOS 27+) up to 2 tappable shortcut cards shown under the pass, each
        {"type": ..., "url": "https://..."}. type is one of: viewSchedule, watchTrailer,
        listenToMusic, call (url must be "tel:+..."), addToBalance, order, shop,
        membershipBenefits, bookAppointment, bookCar, bookFlight, bookStay, viewOffersRewards.
        Works on every style; ignored by older iPhones.
    semantics: machine-readable tags (Apple's SemanticTags) that Wallet uses for Siri/Maps/
        Calendar suggestions on every style, and to lay out the semantic designs below. Values
        are emitted as given; unknown keys and wrong types are rejected. Dates are ISO 8601
        with an offset. Common shapes: passengerName {"givenName", "familyName"}; flightNumber
        is a number (123, not "AI123"); seats [{"seatNumber", "seatRow", "seatSection", ...}];
        venueLocation {"latitude", "longitude"}; totalPrice {"amount": "12.50",
        "currencyCode": "INR"}; eventType one of generic, livePerformance, movie, sports,
        conference, convention, workshop, socialGathering.
    semantic_layout: use Wallet's semantic design, with the classic style kept for older
        iPhones -- which only show primary/secondary/auxiliary fields, so still fill those.
        - boardingPass (iOS 26+, airline only, transit_type "Air"): live flight status, gate
          changes, badges. Requires semantics airlineCode, flightNumber, departureAirportCode,
          departureCityName, destinationAirportCode, destinationCityName, originalBoardingDate,
          originalDepartureDate, originalArrivalDate, passengerName, plus departure and
          destination time zones (IANA, e.g. "Asia/Kolkata"). Apple's docs call these
          departureLocationTimeZone/destinationLocationTimeZone but Apple's pass-builder code
          uses departureAirportTimeZone/destinationAirportTimeZone; either is accepted, and
          giving both is safest.
        - eventTicket (iOS 26+ "poster event ticket"): requires eventName, venueName,
          venueRegionName, venueRoom; sports also needs awayTeamAbbreviation and
          homeTeamAbbreviation, livePerformance needs performerNames. Apple says this design
          is meant for NFC entry, not barcodes, and NFC passes need an Apple entitlement this
          server doesn't have -- Wallet may show the classic event ticket instead.
    info_links: top-level links that fill the event guide (event tickets) or the airline and
        services page (boarding passes). URL keys (http/https): accessibilityURL, addOnURL,
        bagPolicyURL, merchandiseURL, orderFoodURL, parkingInformationURL, purchaseParkingURL,
        sellURL, transferURL, transitInformationURL, contactVenueWebsite,
        directionsInformationURL, changeSeatURL, entertainmentURL,
        purchaseAdditionalBaggageURL, purchaseLoungeAccessURL, purchaseWifiURL, upgradeURL,
        managementURL, registerServiceAnimalURL, reportLostBagURL, requestWheelchairURL,
        transitProviderWebsiteURL. Text keys: contactVenueEmail, contactVenuePhoneNumber,
        transitProviderEmail, transitProviderPhoneNumber.
    Extra images (base64 PNG or https URL). Which image shows where depends on style and iOS version
    (from Apple's Pass Designer docs); Wallet ignores an image a layout has no slot for:
        primary_logo_png_b64: max 126x30pt. Boarding pass and coupon on iOS 27+, event ticket
            on iOS 18+, poster. On those, the plain logo is only shown by older iOS. A wordmark
            is auto-generated for poster and semantic_layout passes unless generate_logo=False.
        secondary_logo_png_b64: max 135x12pt. Event tickets, iOS 18+.
        strip_png_b64: 375x144pt banner behind the primary fields. Coupon, store card and
            event ticket; not shown on iOS 26+ coupon/store card.
        thumbnail_png_b64: 90x90pt. Generic and event ticket.
        artwork_png_b64: 358x448pt poster event ticket artwork (eventTicket with
            semantic_layout, iOS 27+); if neither this nor background_png_b64 is given, a
            gradient in background_color is generated, since Wallet needs one of them.
        background_png_b64 is also used on eventTicket (blurred behind the classic ticket).
    updatable: keep this pass on the server so update_wallet_pass can change it later. The
        response then includes an edit_token: the only way to update the pass, and it can't be
        recovered, so give it to the user. Wallet registers each iPhone that adds the pass, and an
        update reaches them within seconds. The pass contents are stored (other passes only log
        the style and organization_name). Use for passes that change: loyalty points, gate or seat
        changes, memberships that can be cancelled.
    updatable_hours: how long an updatable pass can be updated, 1 (default) to 720 (30 days),
        counted from creation; updates don't extend it. Afterwards the stored pass is deleted and
        can't be changed again, while copies in Wallet stay as they last were. Pick it to cover
        the pass's useful life, e.g. until a flight lands or an event ends. Only with updatable=True.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
styleYes
posterNo
voidedNo
icon_textNo
locationsNo
logo_textNo
semanticsNo
updatableNo
icon_colorNo#c98500
info_linksNo
logo_colorNo
back_fieldsNo
descriptionYes
label_colorNo
icon_png_b64No
logo_png_b64No
max_distanceNo
transit_typeNo
footer_fieldsNo
generate_logoNo
header_fieldsNo
relevant_dateNo
serial_numberNo
strip_png_b64No
barcode_formatNoQR
primary_fieldsNo
artwork_png_b64No
barcode_messageNo
expiration_dateNo
semantic_layoutNo
updatable_hoursNo
auxiliary_fieldsNo
background_colorNo
barcode_alt_textNo
featured_actionsNo
foreground_colorNo
secondary_fieldsNo
organization_nameYes
thumbnail_png_b64No
background_png_b64No
primary_logo_png_b64No
secondary_logo_png_b64No

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare non-read-only, closed-world, non-idempotent, non-destructive; the description goes far beyond by disclosing the 1-hour download_url lifetime, server-side storage duration for updatable passes followed by deletion, that edit_token is irrecoverable, that only style/organization_name are logged for non-updatable passes, and the free-tier/x402 payment behavior including that failed calls count and failed builds are never charged.

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?

Given 42 parameters with three required, the length is largely earned, and the purpose/return/pricing are front-loaded before the long Args block. There is minor redundancy — background_png_b64 is described once in the poster paragraph and again in the extra-images list — and the 'Args:' framing is docstring boilerplate rather than agent-facing prose.

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?

Even without an output schema, the description names the return object fields ({download_url, expires_in_seconds, serial_number, pass_type_identifier}, plus edit_token and updatable_until) and explains conditional population. Combined with the platform/failure/pricing caveats, an agent has everything needed to call this correctly.

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?

Schema description coverage is 0%, so the description carries the full burden — and it does: it documents formats and defaults for barcode_format (including per-format digit/character constraints and iOS-version fallbacks), transit_type enum, hex color syntax, ISO 8601 dates, the locations object shape and max_distance semantics, field-list object shapes, image dimension limits, and the cross-field dependencies (poster requires style generic/storeCard/coupon, footer_fields requires poster=True).

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 opening sentence names the specific verb and resource: 'Create a signed Apple Wallet pass (.pkpass) and return a link to download it.' It also scopes what the tool is NOT ('does not issue tickets, check anyone in, or contact airlines'), which separates it from the sibling update_wallet_pass and from adjacent ticketing workflows.

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 guidance pervades: updatable=True 'Use for passes that change: loyalty points, gate or seat changes,' poster is 'Good for memberships, loyalty cards and gift cards,' and update_wallet_pass is named as the follow-on tool. It also states exclusions ('Not supported: NFC passes') and platform constraints (Safari-only install).

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.