It’s Monday morning, and you’re the account lead on three Shopify Plus clients who all run push through PushEngage. You have a client call in an hour, and before it starts you need last week’s click-through rate for each site’s cart-abandonment sends. Normally that means three separate PushEngage dashboard logins, three separate exports, and three separate mental resets before you’ve said a word to anyone.
This is what managing multiple client accounts with one AI assistant looks like in practice. With the PushEngage MCP server connected to Claude, Cursor, or another agentic assistant, that Monday-morning ritual turns into one conversation. You ask for last week’s CTR on the first site, get it, ask again for the second, get it, ask again for the third, and you walk into the call with all three numbers before your coffee is cold.
Managing multiple client accounts with one AI assistant sounds simple until your roster mixes two different situations: sites you manage under one PushEngage login, and clients who each hold their own separate account. Treat those the same way and you either can’t reach half your clients’ data, or worse, you risk one client’s token touching another client’s account. This is what PushEngage MCP for agencies actually looks like once you get past the demo: two distinct mechanics, not one universal switch. This post covers both, when to use which, and how to use them without opening a single dashboard by hand.
Getting started: connecting PushEngage MCP to your AI assistant
If you haven’t set up the PushEngage MCP server yet, the short version is one command. Add npx -y @pushengage/mcp to your client’s MCP config — Claude Desktop’s claude_desktop_config.json, Claude Code, or Cursor’s mcp.json all accept the same entry — and restart the client. Ask your assistant to “log me into PushEngage,” approve the browser prompt that opens, and your assistant stores an access token locally; your password never touches the chat.
From there, ask “show my PushEngage sites” and “use site [ID]” to pick which one the assistant acts on. Everything below assumes this base setup is already done for at least one account; for the full walkthrough, including troubleshooting a client that won’t connect, see the PushEngage MCP setup guide.
Managing multiple client accounts with one AI assistant means solving two different problems
Agencies running PushEngage across a client roster hit one of two situations, and they need different fixes.
Site switching is what you have when several client sites live under one PushEngage login you manage on the clients’ behalf — a common setup for agencies who onboard clients directly into an agency-owned account. One login, one token, multiple sites to point the assistant at.
Account separation is what you have when each client holds and pays for their own PushEngage account, and logs in independently. Here there is no shared login to switch inside — there are several separate logins, each with its own token, and the job is keeping them from ever mixing.
A rule of thumb settles which one applies: if you’d currently switch sites inside one PushEngage dashboard tab, you want site switching. If you’d currently have to log out of one client’s dashboard to log into another’s, you want account separation. Confusing the two is the mistake worth avoiding: treating separate client accounts as if they were sites under one login is exactly the kind of cross-account mixing that should never happen on client data.
| Site switching | Account separation | |
| Who holds the login | You, on the clients’ behalf | Each client, independently |
| What changes between clients | The selected site | The entire MCP server registration and token file |
| Tools involved | pushengage_list_sites, pushengage_select_site | Separate PE_MCP_CONFIG_PATH per server name |
| Failure mode if you use the wrong one | You never reach a client’s data (if truly separate accounts) | Unnecessary re-authentication overhead (if truly one shared login) |
Most agencies running PushEngage across a full roster end up using both at once: they switch between PushEngage sites inside the handful of clients who share one agency-managed login, and register separate accounts for the clients who insist on holding their own. Nothing about registering multiple PushEngage accounts stops you from also switching sites within any one of them once you’re logged in.
Site switching: pulling CTR across three client sites in one conversation
For the multi-site case, two tools let you switch between PushEngage sites without leaving the conversation: pushengage_list_sites and pushengage_select_site. Every site-scoped tool (analytics, segments, campaign settings) acts on whichever site is currently selected, and the selection persists across restarts, so you set it once per session and every follow-up question in that conversation applies to the same site.
Back to Monday morning. With one login connected, the CTR pull for three client sites looks like this in a single conversation:
- Ask “list my PushEngage sites.” The assistant returns each site’s name and ID.
- Ask to use the first site’s ID, then ask for last week’s click-through rate. The assistant calls
pushengage_get_analytics_timeseriesand returns clicks, views, and CTR by day. - Ask to switch to the second site’s ID. Ask the same question. Repeat for the third.
- Ask for a summary comparing the three. The assistant has already pulled all three data sets in-conversation and can put them side by side.
What makes this worth doing instead of three dashboard exports isn’t just speed. It’s that the numbers you’re pulling are attributable per site, not just raw opens and clicks. pushengage_get_analytics_summary and pushengage_get_analytics_timeseries return clicks, views, and goal value alongside CTR, so the report you walk into the client call with reads as recovered revenue by site, not just engagement counts you’d have to translate for the client yourself.
That framing matters because CTR alone tells only half the story. An industry-wide study on segmentation and click-through rate found CTR moves 2x or more depending on how tightly a client’s sends are segmented, so the same CTR number can mean very different revenue outcomes across three clients with different segmentation maturity. That difference is worth flagging on the call, not just reporting.
This is read-only work. Nothing about switching between PushEngage sites this way sends, schedules, or edits a campaign; pushengage_list_sites and pushengage_select_site only change which site’s existing data the rest of the conversation reads.
Account separation: registering the MCP server under a name per client
For genuinely separate client accounts, the fix lives in the MCP config itself, not in a tool call. PushEngage’s server reads its token location from an environment variable, PE_MCP_CONFIG_PATH, which defaults to ~/.pushengage/mcp.json if you never set it. Register the server twice, once per client, each pointed at its own file, and the two logins never share a token:
{
"mcpServers": {
"pushengage-northwind": {
"command": "npx",
"args": ["-y", "@pushengage/mcp"],
"env": {
"PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-northwind.json",
"PE_MCP_CLIENT_NAME": "Claude Desktop (Northwind)"
}
},
"pushengage-brightleaf": {
"command": "npx",
"args": ["-y", "@pushengage/mcp"],
"env": {
"PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-brightleaf.json",
"PE_MCP_CLIENT_NAME": "Claude Desktop (Brightleaf)"
}
}
}
}(Northwind and Brightleaf are illustrative client names.) PE_MCP_CONFIG_PATH must be an absolute path — it’s used exactly as given, with no ~ expansion, so double-check the path before restarting your client. PE_MCP_CLIENT_NAME is optional and only changes the label your assistant shows on PushEngage’s own authorize screen; it doesn’t affect isolation, but it’s worth setting so you can tell which client you authorized when the browser tab opens.
Log into each server name separately: “log me into pushengage-northwind,” then, in a later step, “log me into pushengage-brightleaf.” Each authorizes against whichever PushEngage account you choose in that specific browser session. Two server names, two config files, two tokens that never touch. This is the pattern for running multiple PushEngage accounts side by side, and it scales past two: an agency with a dozen client accounts registers a dozen server entries, each with its own PE_MCP_CONFIG_PATH, and none of them ever share a file. It’s also the piece most competing “multi-client AI” guides skip past with vague talk of isolation instead of an actual config to copy.
Running the same segment-creation prompt across every client account
Once your clients are registered as separate server names, you can replay one request across all of them without ever opening a dashboard. Say you want a “visitors of /pricing” segment live on five client accounts before end of day. Ask your assistant, in turn, to “create a segment for visitors of /pricing” against pushengage-northwind, then pushengage-brightleaf, then each remaining client server name. Each request calls pushengage_create_segment against that account’s own token, and each client ends up with the same URL-rule segment, built on their own subscriber base.
The reason the same prompt transfers cleanly across five different clients’ accounts is that it’s invoking a segmentation model PushEngage ships built in, not something you’re architecting from scratch per client. pushengage_list_segments and pushengage_create_segment work off URL rules and behavioral criteria the platform already understands — recency, frequency, page-visit patterns — the same categories that make the ecommerce segmentation guide‘s approach work as a system rather than a one-off list. That’s what lets one prompt do real segmentation work five times over instead of five separate manual builds. And because segmentation is now a deliverability requirement rather than a nice-to-have, replaying it across every client account is closer to standard account hygiene than a shortcut.
Keeping a former team member’s access out of every other client’s account
Account separation earns its keep the day someone rolls off an account. Because each client’s token lives in its own config file, removing one person’s access to one client never touches the rest of your roster.
Two ways to close it out:
- Locally: log out of just that client’s server registration — “log me out of pushengage-northwind” calls
pushengage_auth_logout, which deletes the token from that one config file and leaves every other client’s file untouched. - Server-side: if the departing team member authorized the browser session themselves, revoke it from inside PushEngage under Settings → Security on that specific client’s account, which invalidates the token regardless of where it’s stored locally.
Compare that to what happens with a single shared login across clients: revoking access means rotating one shared token, which breaks every teammate’s connection to every client at once. Keeping each client on its own PE_MCP_CONFIG_PATH turns a roster-wide fire drill into a one-line fix.
What this changes for how an agency prices and staffs multi-client push work
None of this changes what push notifications do for a client’s retention numbers. PushEngage’s MCP server doesn’t send, schedule, or build campaigns on its own; every pushengage_send_notification or pushengage_send_ab_notification call still runs against one site at a time, with you approving it. What changes is the time between “the client wants to know their numbers” and “the client has their numbers,” and time is the one resource an account manager can’t buy more of mid-month.
That’s the real value of managing multiple client accounts with one AI assistant: not a new capability, but time back. It matters at the scale PushEngage already runs at — 25,000+ business owners across 150+ countries sent 15.2 billion notifications through the platform in the last 30 days alone.
An agency managing a handful of those accounts isn’t asking this infrastructure to do something new; it’s asking to reach the reporting and audience-building work it already does, without a dashboard login standing between the assistant and the answer. The account manager who used to spend Monday mornings exporting three CSVs now spends that time on what those numbers say about each client’s repeat-purchase rate. That’s the part of the job that was never supposed to be about logins in the first place.
Whether your roster needs site switching, account separation, or both, the mechanics above run on every PushEngage plan, priced to scale with active subscribers rather than per client account, so adding the fourth or fifth client to this setup doesn’t mean renegotiating what you pay to reach them. That’s the actual shape of PushEngage MCP for agencies: not a new manager-account tier bolted on top, but the same two mechanics (one login with several sites, or several logins that never cross) applied to however many clients you’re running this quarter.
