Why a beginner’s guide to using an MCP server has to start with what you’re afraid of
You’ve never pasted an API key into a chat window, and you’re not about to start now. That’s the real reason you’ve put off connecting an AI assistant to your push notification account for months. You don’t doubt it would work; you just don’t trust yourself not to break something, or send the wrong message to real subscribers while you’re still learning where the buttons are.
This is a beginners guide to using an MCP server, specifically PushEngage MCP, the official Model Context Protocol server for PushEngage, written the only way that actually proves whether one of these things is safe to hand your account to: as a real week, day by day, not a five-minute demo that stops the moment the connection turns green. Most guides to setting up an MCP server end at “it’s connected.” This one keeps going, because a founder deciding whether to trust a tool with real sends needs to see it do a full week of ordinary work, not one canned test call.
PushEngage MCP already runs at real scale before you ever touch it: 25,000+ business owners in 150+ countries send through PushEngage, 15.2 billion notifications went out in the last 30 days alone, across 27 tools spanning 10 domains of the account. That volume matters for one reason: the mistakes a first-time user is afraid of making have mostly already been made, and fixed, by people who aren’t you.
Here’s the week. Day one is install and login, and nothing else. Day two is the first real send. Day three is a scheduled send that has to land at the right hour for subscribers in different time zones. Day five is the first time you ask a plain question about how any of it actually performed. By the end, something specific will have changed about how you run the business, not just about how you use a tool. PushEngage’s web push notifications are the channel all of it runs through.
Day 1: installing PushEngage MCP without ever typing an API key
The whole mcp server setup takes about ten minutes, and none of those ten minutes involve you generating, copying, or pasting a credential anywhere. That single fact is the entire reason this week is worth trying.
Adding the server to your assistant
PushEngage MCP ships as an npm package, @pushengage/mcp, and the install command is one line: npx -y @pushengage/mcp. There is nothing to download ahead of time and nothing to keep updated yourself. npx fetches the current version the moment your assistant runs it. You need Node.js 18 or newer already on your machine and an MCP-capable client (Claude Desktop, Claude Code, Cursor, or any other), but you do not need to write a line of code.
If you’re using Claude Desktop, the claude mcp server config lives in a file called claude_desktop_config.json (on macOS, under ~/Library/Application Support/Claude/). You open it and paste this block in:
{
"mcpServers": {
"pushengage": {
"command": "npx",
"args": ["-y", "@pushengage/mcp"]
}
}
}Save the file and restart Claude Desktop. “pushengage” should appear in your tool list.
Cursor works the same way, just in a different file, ~/.cursor/mcp.json, with the identical block pasted in. Claude Code doesn’t ask you to hand-edit a JSON file at all; you register the same claude mcp server with one terminal command, claude mcp add pushengage -- npx -y @pushengage/mcp, and it’s available in every session from that point on. Whichever client you use, the shape of the work is the same: copy a short block, or type one line, and restart. Nobody is asking you to write software.
What happens when you click Authorize
Once the server shows up, ask your assistant: “Log me into PushEngage.” A browser tab opens to PushEngage’s own authorize page, not a form embedded in your chat window: an actual browser tab, on PushEngage’s own domain. You click Authorize. The tab confirms success, and an access token gets saved to a file on your machine, ~/.pushengage/mcp.json, readable only by your own user account.
At no point does your assistant see your PushEngage password. The dashboard sends the token to the server as a background request, so it never shows up in a URL, your browser history, or anyone’s access log. This is the part of an mcp server for beginners that matters most: the credential lives between your browser and PushEngage directly, and the AI never sits in that path at all.
Choosing which site is “current”
Ask “Show my PushEngage sites,” then “Use site [whichever one you meant].” That selection sticks. It persists across restarts, so you won’t re-pick it every time you open a new chat. Every site-scoped tool from here on acts on that current site unless you name a different one explicitly, which matters the moment you run more than one property. If you only have one site under your account, this step takes ten seconds and you never think about it again. If you run two storefronts under one PushEngage account, this is also the moment to notice you’ll want to say which one you mean on any request that touches subscribers, sends, or analytics. The assistant won’t guess.
When day 1 doesn’t go smoothly: the two things that actually go wrong
Most mcp server setup problems trace back to one issue, and it isn’t PushEngage’s fault or yours: it’s how desktop apps launch. If Claude Desktop or Cursor reports the server as disconnected, or you see something like MCP error -32000: Connection closed, but typing npx -y @pushengage/mcp directly into your own terminal works fine, that’s a PATH problem. Apps launched from your Dock or Finder don’t load your shell’s startup files, so if Node was installed through a version manager, the app literally can’t find npx.
The fix is to point your client at the absolute path to npx instead of relying on it to find it. Run which npx in your terminal to get that path, then use it directly:
{
"mcpServers": {
"pushengage": {
"command": "/absolute/path/from/which-npx",
"args": ["-y", "@pushengage/mcp"],
"env": {
"PATH": "/absolute/folder/containing/that/npx:/usr/bin:/bin:/usr/sbin:/sbin"
}
}
}
}Restart the client after editing. If which npx printed something under /usr/local/bin or /opt/homebrew/bin instead, this probably isn’t your issue. Check your client’s own MCP logs for the real error.
Three smaller messages are worth knowing before you hit them, because none of them mean something is broken:
AUTH_EXPIRED— your token expired. Ask the assistant to log you in again.NO_SITE_SELECTED— you skipped the “use site” step. List your sites and pick one.- Browser doesn’t open — this only happens in headless or remote sessions. The authorize link prints to the terminal instead; open it by hand.
Every other error the server returns starts with a [CODE] tag and a plain-language explanation, which is the detail worth remembering when something looks scary at 11pm on a Tuesday: it isn’t silent, and it isn’t cryptic on purpose.
Day 2: the first “just send this now” request
By day two, install is done and forgotten. This is where AI assistant push notifications stop being an idea and become one specific message, going to one specific group of people, right now.
You ask: “Send a notification to my cart-abandoners titled ‘Still thinking it over?’, message ‘Your cart’s waiting — complete it today,’ linking to my cart page.”
Your assistant doesn’t fire that immediately. It restates exactly what it’s about to send: the title, the message, the link, and which audience group it’s targeting, then waits for you to confirm before pushengage_send_notification sends it. If you named an audience group PushEngage already has (cart-abandoners, in this example), the send goes only to that segment; if you didn’t specify one, it would go to every subscriber, which is worth noticing before you approve anything.
Nothing goes out that you didn’t see first. That’s the whole point of sending and scheduling push notifications from your AI assistant instead of a dashboard: the confirmation step is built into the conversation itself, not a separate screen you have to remember to check.
Day 3: a scheduled send that lands at 9 AM in every subscriber’s own timezone
Day three is where a founder’s real hesitation about automation shows up: what happens if this fires while I’m not watching, and will it fire at the right time for someone who isn’t in my timezone?
pushengage_send_notification has a scheduled mode built for exactly this. You ask for a one-shot send timed for “9 AM in each subscriber’s local timezone,” and the tool schedules delivery so a subscriber in Lisbon and a subscriber in Manila both get it at their own 9 AM, not yours. The send still needs your approval before it schedules, the same as day two; only the timing changes.
Recurring sends exist too (you could set up a weekly digest the same way), but day three is deliberately just the one-shot version. You don’t need to trust the tool with a standing recurring job before you’ve watched a single scheduled send land correctly.
Per-subscriber timezone delivery is the detail worth sitting with, because it’s easy to assume a “scheduled send” just means “send later” and miss what’s actually different here. If a quarter of your subscribers are nowhere near your own timezone, a single fixed send time means most of them either get it while asleep or hours after the moment it was meant to matter. Splitting delivery by each subscriber’s own local time means a 9 AM send is a 9 AM send everywhere it lands, which is the difference between a notification someone sees at breakfast and one that’s buried by lunch.
Day 5: asking “how did that do?” instead of opening a dashboard
By day five, you’ve sent something and scheduled something. The next question a founder actually asks isn’t about the tool. It’s about the business: was any of that worth doing.
You ask: “How many subscribers do I have, and what was my click rate on that cart-abandoner send?” pushengage_get_analytics_summary and pushengage_get_analytics_timeseries answer directly, in the chat, with real numbers: subscriber count, sends, views, clicks, and click-through rate for the window you asked about.
Say the cart-abandoner send from day two came back with a CTR meaningfully higher than your usual sitewide blasts. That’s not just a bigger number to feel good about. Illustratively, if even a modest share of those extra clicks complete a purchase, that’s recovered cart revenue you’d otherwise have written off, not just an engagement stat. That’s the actual decision day five is for: not “did people open it,” but “is this worth doing again, and to which segment.” For a longer view across multiple sends, week-by-week push performance reporting and push notification analytics explained in plain English go deeper than a single day-five question can.
What actually changed by the end of the week
Nothing about push notifications changed this week. What changed is where the work happens.
You didn’t open a separate dashboard tab to check subscriber counts. You didn’t send a message to a developer asking them to “just change the send time” on the scheduled notification. You didn’t context-switch between running the business and operating the push tool. The request, the confirmation, and the result all happened in the same conversation you were already having.
That’s a smaller shift than it sounds like, and also a bigger one. Smaller, because nothing about the underlying channel changed. Web push still works the way it always did, and the notifications that went out this week are indistinguishable from ones sent through the dashboard. Bigger, because the tab you didn’t open is the tab that used to be the reason this kept getting pushed to “later.” A task that requires switching apps, remembering a login, and finding the right screen competes with everything else on a founder’s list and usually loses. A task that happens inside a conversation you were already having doesn’t compete with anything. It just gets done.
That matters most because none of it required a budget decision first. PushEngage MCP works with every PushEngage plan, including the free tier. You weren’t testing a scaled-down preview of the experience this week; you were using the same tools a paid account uses, on ordinary access. If the numbers from day five make the case for doing more of this, PushEngage’s pricing page is the next stop, and it scales with active subscribers rather than asking for a commitment before you’ve proven anything to yourself.
What this beginner’s guide didn’t cover, and where to go deeper
Worth being direct about what this week didn’t touch, because a guide that only tells you what a tool does and never what it doesn’t is the kind of guide that gets you into trouble later.
PushEngage MCP can list and read your drip campaigns, triggered campaigns, and workflows. It cannot build them for you. If you want a new automation, you’re still building it in the dashboard; the assistant can only tell you what’s already running and how it’s performing. It doesn’t send WhatsApp messages, and there’s no remote or hosted version to connect from a browser somewhere else. This is a local server, run through npx, talking to your account over a standard protocol connection, nothing more.
None of that limits the week you just had. If you want the full reference version of everything in day one (every config option, every client, every troubleshooting case), the full PushEngage MCP setup guide covers it as documentation rather than narrative.
That’s the honest shape of a beginners guide to using an MCP server: five real days, one plain-language request at a time, and you finishing the week doing the same work in fewer places than you started it in.
