walletmcppass: Apple Wallet passes
Server Details
Create signed Apple Wallet passes (.pkpass): boarding passes, tickets, coupons, store cards.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- arshwaraich/wallet-mcp
- GitHub Stars
- 0
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: create_wallet_pass builds and signs a pass, update_wallet_pass modifies an existing updatable pass. The update tool explicitly requires the serial_number and edit_token produced at creation, so there is no plausible way to confuse them.
Both names follow the same verb_noun_wallet_pass pattern (create_wallet_pass, update_wallet_pass), with a consistent snake_case convention and a shared domain noun.
Two tools sit at the thin end of the range: the create/update lifecycle pair is coherent, but there is no way to query, list, or delete stored updatable passes, so the surface is minimal rather than well-rounded for the described feature scope.
The create/update pair covers the core lifecycle, and voided=True provides cancellation semantics while the update expiry handles cleanup. Minor gaps remain (no get/list of stored passes, no explicit delete before updatable_hours), but these are largely inherent to Wallet's push-based model and agents can work around them.
Available Tools
2 toolscreate_wallet_passCreate Apple Wallet passAInspect
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.| Name | Required | Description | Default |
|---|---|---|---|
| style | Yes | ||
| poster | No | ||
| voided | No | ||
| icon_text | No | ||
| locations | No | ||
| logo_text | No | ||
| semantics | No | ||
| updatable | No | ||
| icon_color | No | #c98500 | |
| info_links | No | ||
| logo_color | No | ||
| back_fields | No | ||
| description | Yes | ||
| label_color | No | ||
| icon_png_b64 | No | ||
| logo_png_b64 | No | ||
| max_distance | No | ||
| transit_type | No | ||
| footer_fields | No | ||
| generate_logo | No | ||
| header_fields | No | ||
| relevant_date | No | ||
| serial_number | No | ||
| strip_png_b64 | No | ||
| barcode_format | No | QR | |
| primary_fields | No | ||
| artwork_png_b64 | No | ||
| barcode_message | No | ||
| expiration_date | No | ||
| semantic_layout | No | ||
| updatable_hours | No | ||
| auxiliary_fields | No | ||
| background_color | No | ||
| barcode_alt_text | No | ||
| featured_actions | No | ||
| foreground_color | No | ||
| secondary_fields | No | ||
| organization_name | Yes | ||
| thumbnail_png_b64 | No | ||
| background_png_b64 | No | ||
| primary_logo_png_b64 | No | ||
| secondary_logo_png_b64 | No |
TDQS
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.
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.
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.
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.
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.
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.
update_wallet_passUpdate Apple Wallet passADestructiveIdempotentInspect
Change a pass made with create_wallet_pass(updatable=True); every iPhone that added it refreshes.
Takes the serial_number and edit_token returned when the pass was created, plus any of
create_wallet_pass's parameters, with the same meanings. Each parameter given replaces the
stored value completely (a fields list replaces the whole list, so resend unchanged fields
too); parameters left out keep their current values. Clear a text value with "" and a list
with []. To cancel a pass, set voided=True: Wallet marks it void on every iPhone.
Wallet asks the server for the new version as soon as Apple delivers the push, usually within
seconds. A field's changeMessage is shown on the lock screen when that field's value changes.
Only works until the pass's updatable_until time (set by updatable_hours at creation).
Returns {download_url, expires_in_seconds, serial_number, pass_type_identifier,
notified_devices, updatable_until}. notified_devices counts the iPhones the push was sent to, not ones that
have already refreshed. The download_url (valid 1 hour) is only needed to add the pass to a
new device.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | ||
| poster | No | ||
| voided | No | ||
| icon_text | No | ||
| locations | No | ||
| logo_text | No | ||
| semantics | No | ||
| edit_token | Yes | ||
| icon_color | No | ||
| info_links | No | ||
| logo_color | No | ||
| back_fields | No | ||
| description | No | ||
| label_color | No | ||
| icon_png_b64 | No | ||
| logo_png_b64 | No | ||
| max_distance | No | ||
| transit_type | No | ||
| footer_fields | No | ||
| generate_logo | No | ||
| header_fields | No | ||
| relevant_date | No | ||
| serial_number | Yes | ||
| strip_png_b64 | No | ||
| barcode_format | No | ||
| primary_fields | No | ||
| artwork_png_b64 | No | ||
| barcode_message | No | ||
| expiration_date | No | ||
| semantic_layout | No | ||
| auxiliary_fields | No | ||
| background_color | No | ||
| barcode_alt_text | No | ||
| featured_actions | No | ||
| foreground_color | No | ||
| secondary_fields | No | ||
| organization_name | No | ||
| thumbnail_png_b64 | No | ||
| background_png_b64 | No | ||
| primary_logo_png_b64 | No | ||
| secondary_logo_png_b64 | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (destructiveHint, idempotentHint), disclosing that each supplied parameter overwrites the stored value wholesale, that lists must be resent in full, that "" and [] clear values, that omitted parameters are preserved, that voided=True kills the pass on every device, that the push refresh is near-immediate, that changeMessage surfaces on the lock screen, and that the operation expires at updatable_until. This is exactly the mutation-side-effect detail an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core identity and precondition, then layered update semantics, then propagation behavior, then return contract. Every sentence resolves a real ambiguity (list replacement, no-op on omission, notified_devices counting sends not refreshes). No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 41-parameter mutation with no output schema, this covers returns, mutation semantics, expiry, and propagation, which is most of what an agent needs. The remaining gap is that individual parameter meanings are inherited by reference to the sibling tool rather than restated here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 41 parameters, so the description must carry the load. It does explain the replace-not-merge semantics, the clear-value syntax, voided, and where serial_number/edit_token come from, which is high-value, but it explicitly defers individual parameter meanings to create_wallet_pass rather than documenting them, leaving the per-field semantics external.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Change a pass made with create_wallet_pass(updatable=True)') and immediately distinguishes itself from the create sibling by naming the upstream tool and the precondition for using this one. An agent can tell the two apart without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the sibling tool and the condition that produces the pass being edited (updatable=True), and gives an explicit when-not boundary ('Only works until the pass's updatable_until time'). It stops short of an explicit routing sentence like 'to create a pass, use create_wallet_pass', so it is clear context rather than a full when/when-not/alternatives map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
create_wallet_pass - First observed
update_wallet_pass
Related MCP Connectors
Create, update and message Apple Wallet and Google Wallet passes and loyalty cards.
Create, update, and revoke Apple Wallet and Google Wallet passes from any MCP client.
JSON in, PDF out. Render invoices, certificates, reports and cards from a template and a payload.
Generate images, videos and PDFs from templates. Manage templates, folders, uploads and fonts.
Related MCP Servers
AlicenseAqualityCmaintenanceRender branded PDF documents (invoices, reports, certificates) and PNG social images directly from any MCP client using DocJet templates or raw HTML with JSON data.319 npmMIT- AlicenseNot gradedqualityBmaintenance31 deterministic utility tools over one public endpoint: image conversion and lossless EXIF/metadata stripping, App Store screenshot/icon/favicon generation, WCAG and OKLCH colour maths, .strings and provisioning-profile checks, plus TDEE, recipe and plant calculators. No API key, no account, no model calls.ISC

Embossofficial
AlicenseNot gradedqualityAmaintenanceTurn flat PDFs into fillable forms and fill them from data, documents, or a spreadsheet. Remote MCP server (Streamable HTTP) with OAuth sign-in at https://api.getemboss.ai/mcp, no local install required.MIT- AlicenseNot gradedqualityDmaintenanceEnables PDF and image generation from templates, JSON, HTML, or URLs through the PDF Gen Studio API. Supports rendering, template management, and multiple output formats.11 npm1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.