Pushlane Push Notification MCP Server Guide

A push notification MCP server gives a coding agent structured tools for integration work. It does not give the model permission to improvise an SDK, invent event names or declare a migration complete because code was generated.

Pushlane exposes a remote MCP endpoint for Claude Code, Cursor and other compatible clients. The agent can inspect the supported setup path, detect the app platform, plan instrumentation, submit existing notification logic for replication and verify that data arrived. The important distinction is that each of those steps returns evidence, not a promise.

This guide shows how to use that workflow for a subscription app without replacing your analytics, duplicating purchase events or deleting working notification code too early.

What the Pushlane MCP server can do

MCP is an open protocol for connecting AI applications to external tools and data. The official Model Context Protocol introduction explains the client, server and tool model.

Pushlane runs its MCP server at the same ingest service used by the app. A client connects over Streamable HTTP with the workspace write key. The workspace is derived from that key, so a tool argument cannot select a different tenant.

The current tool set covers five jobs:

1. Ground the setup. get_setup_info returns the ingest URL, workspace identity and RevenueCat identity contract.
2. Choose the real platform path. detect_platform classifies iOS, Expo, React Native, Flutter, Android or web from repository signals. get_install_instructions then returns the supported install for that platform.
3. Plan events. get_recommended_events, get_catalogue and plan_instrumentation reconcile proposed tracking with events already used by the app.
4. Replicate existing notifications. submit_notification_brief queues a structured migration, while get_replication_status reports what became live and what did not.
5. Prove the connection. verify_integration checks whether events or devices have actually reached Pushlane.

The complete, current arguments and responses live in the Pushlane MCP documentation. Read that page as the contract. A model's memory of an older tool name is not the contract.

The server does not currently provide a general tool for sending arbitrary pushes, editing every flow, or querying all campaign analytics. If an agent claims those controls exist, stop and call tools/list.

Start with an idempotent setup plan

Ask the agent to call get_setup_playbook before it edits the app. The playbook defines the supported order and the markers used to keep a second run clean.

A safe session looks like this:

1. Call get_setup_info and get_setup_playbook.
2. Inspect repository signals and call detect_platform.
3. Call get_install_instructions with the detected platform.
4. Find existing analytics and notification code.
5. Call get_catalogue and plan_instrumentation.
6. Apply the smallest platform-correct code change.
7. Build and run the app once.
8. Call verify_integration until the evidence is current.
9. Connect RevenueCat server-side.
10. Replicate existing notification briefs and poll their status.

Keep the generated changes in a normal branch. Review the diff like any other SDK integration, especially setup order, identity calls, token registration and logout handling. MCP makes repository-specific instructions available to the agent; it does not replace code review.

On a re-run, use the playbook rather than asking the agent to layer another install on top. For notification replication, replaceExisting: true archives flows previously created by that replication path before replacing them. It does not authorize the agent to archive unrelated flows.

Install the platform that exists, not the package you expect

Pushlane's supported installation differs by platform.

• Native iOS uses the published Swift package.
• Expo, React Native, Flutter and Android currently use a generated drop-in client that works with the notification library already present in the app.
• Event tracking works across those supported drop-ins.
• End-to-end delivery is currently proven on iOS through APNs. Android and Flutter can register FCM tokens and send events, but Pushlane does not yet deliver FCM pushes.

That last limitation matters during an automated integration. A successful Android registration is not evidence that a notification can be delivered by Pushlane. The agent should preserve that distinction in code comments, test plans and status reports.

Do not let the agent install a package name merely because it looks plausible. The MCP install tool returns the current source of truth, including the full drop-in when a registry package does not exist. For an Expo example, compare the result with the Expo and RevenueCat setup guide.

Mirror product events without corrupting the taxonomy

Most subscription apps already send events to an analytics provider. Keep those calls. Add Pushlane tracking alongside them at the same product action.

The agent should first inventory three groups:

• product events that already exist, such as workout_completed or budget_created;
• Pushlane auto-emitted events, including app_open and session_started;
• reserved delivery telemetry names that must not be reused for product behavior.

Then call plan_instrumentation with the existing names. The response can identify events to mirror, names to rename and auto-emitted events to skip. This prevents two common failures: counting one action twice and choosing a reserved name that cannot start a flow.

Use observable actions rather than inferred labels. lesson_completed is testable. high_intent_user is an interpretation that will drift unless someone defines and maintains it.

After the change, run the app through at least one real product action and call verify_integration. A build that compiles proves only that the client code is syntactically valid. Verification should show a recent event or registered device from the intended workspace.

Keep subscription events on the server path

Do not add client-side trial_started, renewal or cancellation tracking just to make a lifecycle flow easier to build. Those events can be wrong, duplicated or emitted before the store state is final.

Pushlane receives verified lifecycle transitions through its RevenueCat webhook. Identity joins only when the RevenueCat App User ID matches the external ID passed to Pushlane. RevenueCat's official customer identity guide explains why a stable App User ID matters across devices and restores.

The implementation sequence is:

1. Use one stable account ID in Pushlane and RevenueCat.
2. Generate the dedicated RevenueCat webhook secret in Pushlane.
3. Configure the server-to-server webhook in RevenueCat.
4. Send a dashboard test event to prove authentication.
5. Run a sandbox lifecycle to prove the real event mapping.
6. Guard production flows with the observed environment properties.

The detailed setup is in the RevenueCat integration guide. A dashboard test confirms transport and authentication. It does not prove that a purchase, renewal or cancellation will enter the intended flow.

Migrate existing notifications with proof gates

If the app already schedules local notifications or calls another push service, the agent can describe each existing path in a structured brief. Pushlane queues those briefs for replication as flows.

Treat the returned states literally:

• queued means the job was accepted, not published;
• live means a flow activated;
• fullyReplicated means the brief was reproduced without a material caveat;
• safeToRemove is the explicit gate for deleting the matching local implementation.

Never remove all existing notification code because one job has a live count greater than zero. Match each result to the original trigger and message. Preserve any path that was skipped, only partially represented or still waiting on an event that cannot fire.

Also check for duplicate ownership. A local reminder and a live server flow can both fire if the migration leaves both active. Use a test account, force the exact trigger and confirm that only one system owns the notification before cleanup.

Finish with evidence, not a generated summary

A push notification MCP server is most useful when it shortens the path from repository inspection to a verifiable integration. End the session with a compact evidence table:

That is the useful boundary for agentic setup. Let the agent gather the current instructions and perform the mechanical integration, then require runtime evidence at every handoff. Start with the Pushlane MCP reference, keep the RevenueCat automation blueprints nearby, and do not turn an agent's confidence into a production status.