walletmcppass: Apple Wallet passes
Server Details
Create signed Apple Wallet passes (.pkpass) from any MCP client: boarding passes, event tickets, coupons, store cards and generic passes. No Apple Developer account needed. Supports updatable passes that refresh on iPhones, lock-screen locations, and image URLs. Free for 30 calls a day, then $0.01 a call via x402.
- Status
- Healthy
- Uptime
- 99.9% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 2 tools
The two tools map to clearly separate lifecycle stages: create_wallet_pass builds a new pass and update_wallet_pass mutates an existing one identified by serial_number + edit_token. There is no overlap or plausible way to confuse them, and the update tool explicitly states its precondition (pass created with updatable=True).
Both names follow the same snake_case verb_noun pattern (create_wallet_pass / update_wallet_pass) with a shared domain object, making the set fully predictable.
Only two tools, which is on the thin side even for a narrow signing service, though both are substantial and earn their place. Nothing indicates missing sibling endpoints, but the surface is small enough to feel minimal.
The core lifecycle is covered: create, update, void (via voided=True on update), and expiry/cleanup through updatable_hours. Minor gaps exist—there is no way to read back a stored pass's current state or serials without changing them—but agents can work around this by keeping the edit_token and download_url themselves.
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, and x402_setup (how to set up x402
payments, worth passing on to the user) when x402_ready=False.
Pricing: a call is one create or one update. Free for 30 calls a day per caller IP (20 from
2026-11-18), 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.
contact_email: required. The user's address, so the operator of this service can reach them
about it, for example if it changes or breaks for them. Ask the user for it; never take it
from the pass details or make one up. It isn't added to the pass, and it's kept in the
request log.
x402_ready: required. True if this client can pay with x402, False if it can't, "unknown" if
you don't know. It shows the operator how many clients could pay past the free limit.
Only logged: it changes neither price nor limits.| 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 | ||
| x402_ready | Yes | ||
| back_fields | No | ||
| description | Yes | ||
| label_color | No | ||
| icon_png_b64 | No | ||
| logo_png_b64 | No | ||
| max_distance | No | ||
| transit_type | No | ||
| contact_email | Yes | ||
| 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?
Beyond the annotations, the description discloses the signing certificate behavior, one-hour download URL, Safari-only installation, barcode compatibility by iOS version, server-side storage for updatable passes, edit_token irrecoverability, rate limits, x402 pricing, and exact response fields. These are substantive behavioral details not present in the structured annotations.
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?
It is front-loaded and dense with useful detail, which is justified by the 44-parameter schema with no field descriptions. It is still very long and repeats some information, such as barcode format support in both the overview and the Args section, so it falls short of ideal conciseness.
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?
Despite lacking an output schema, the description specifies the returned object fields, conditional fields, storage lifetime, and pricing behavior. It also covers edge cases, such as older iOS fallback layouts and unsupported formats, making it complete for this complex tool.
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 44 parameters, so the description carries the full burden, and it does so thoroughly: every parameter is explained with constraints, defaults, examples, allowed values, and interactions such as poster requiring style generic/storeCard/coupon. It adds far more meaning than the bare schema provides.
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 description opens with a specific verb and resource: create a signed Apple Wallet pass and return a download link. It clearly distinguishes itself from the sibling tool by explaining that updatable=True enables later changes through update_wallet_pass.
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?
It gives explicit when-to-use context across pass styles and updatable passes, and it states when not to use it: it does not issue tickets, check anyone in, contact airlines or venues, or support NFC passes. The sibling relationship is also made explicit.
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, the required
contact_email and x402_ready, 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. With x402_ready=False the result also has x402_setup, as for create_wallet_pass.
| 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 | ||
| x402_ready | Yes | ||
| back_fields | No | ||
| description | No | ||
| label_color | No | ||
| icon_png_b64 | No | ||
| logo_png_b64 | No | ||
| max_distance | No | ||
| transit_type | No | ||
| contact_email | Yes | ||
| 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?
Annotations already carry the safety profile (destructive, idempotent, not read-only), and the description adds real substance beyond them: push-propagation timing, per-device voiding, changeMessage lock-screen behavior, and the expiration window. It stops short of saying what happens to an already-voided pass or whether a failed push is retried, but the key destructive consequences are disclosed.
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?
Dense and front-loaded — purpose and refresh behavior come first, then input contract, then edge cases, then returns. Nearly every sentence earns its place, though the wrapping around 'the required contact_email and x402_ready' reads awkwardly mid-sentence and the return-value paragraph is longer than strictly necessary.
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 43-parameter mutation tool with no output schema, coverage of lifecycle (updatable_until), destruction (voided), async propagation, and return fields including the notified_devices caveat is strong. The gap is per-parameter meaning: an agent must open create_wallet_pass's schema to interpret fields like style, semantic_layout, transit_type, or featured_actions.
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?
With 43 parameters at 0% schema description coverage, the description does the heavy lifting on the most error-prone semantics: replace-not-merge ('a fields list replaces the whole list, so resend unchanged fields too'), omit-to-preserve, and empty-value clearing. The remaining ~35 optional parameters are handled by reference ('any of create_wallet_pass's parameters, with the same meanings'), which is efficient but forces a second lookup, and the 'unknown' enum value on x402_ready is never explained.
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?
Opens with a specific verb+resource ('Change a pass') and immediately scopes it to passes created with create_wallet_pass(updatable=True), naming the sibling tool. The downstream effect ('every iPhone that added it refreshes') further distinguishes it from a mere local edit.
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?
Explicitly states prerequisites (edit_token and serial_number from creation), the hard boundary ('Only works until the pass's updatable_until time'), and the cancellation path ('set voided=True'). The clearing conventions ('Clear a text value with "" and a list with []') are the kind of when-to-do-what guidance an agent would otherwise get wrong.
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
- Changed
create_wallet_pass2 fields changed- added
Input schema / properties / x402_ready / enumAdded value: +[ + true, + false, + "unknown" +] - removed
Input schema / properties / x402_ready / typeRemoved value: -"boolean"
- Changed
update_wallet_pass2 fields changed- added
Input schema / properties / x402_ready / enumAdded value: +[ + true, + false, + "unknown" +] - removed
Input schema / properties / x402_ready / typeRemoved value: -"boolean"
2 tool updates
- Changed
create_wallet_pass7 fields changed- removed
Input schema / properties / contact_email / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - removed
Input schema / properties / contact_email / defaultRemoved value: -null - added
Input schema / properties / contact_email / typeAdded value: +"string" - removed
Input schema / properties / x402_ready / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - removed
Input schema / properties / x402_ready / defaultRemoved value: -null - added
Input schema / properties / x402_ready / typeAdded value: +"boolean" - changed
Input schema / requiredPrevious value: -[ - "style", - "organization_name", - "description" -]New value: +[ + "style", + "organization_name", + "description", + "contact_email", + "x402_ready" +]
- Changed
update_wallet_pass7 fields changed- removed
Input schema / properties / contact_email / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - removed
Input schema / properties / contact_email / defaultRemoved value: -null - added
Input schema / properties / contact_email / typeAdded value: +"string" - removed
Input schema / properties / x402_ready / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - removed
Input schema / properties / x402_ready / defaultRemoved value: -null - added
Input schema / properties / x402_ready / typeAdded value: +"boolean" - changed
Input schema / requiredPrevious value: -[ - "serial_number", - "edit_token" -]New value: +[ + "serial_number", + "edit_token", + "contact_email", + "x402_ready" +]
2 tool updates
- Changed
create_wallet_pass2 fields changed- added
Input schema / properties / contact_emailAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Contact Email" +} - added
Input schema / properties / x402_readyAdded value: +{ + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "default": null, + "title": "X402 Ready" +}
- Changed
update_wallet_pass2 fields changed- added
Input schema / properties / contact_emailAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Contact Email" +} - added
Input schema / properties / x402_readyAdded value: +{ + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "default": null, + "title": "X402 Ready" +}
2 tool updates
- First observed
create_wallet_pass - First observed
update_wallet_pass
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceRemote MCP server that lets AI assistants read tracked competitive intelligence — competitor news, reviews, website changes, social posts and ads — and act on it by managing projects, competitors, battle cards, reports and canvases. Every answer carries a source and a date, and write actions only publish when explicitly shared.MIT
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs115 npm58 PyPIMIT
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.1623 npm1MIT

industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.