Userport

Userport is customer support and outbound messaging for SaaS founders.

Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeRead-only

What it can do

  • Userport Workspaces: Every workspace this account can reach, with its handle and the current state of its inbox: how many conversations are open, unread, snoozed, closed and spam, plus how email is se
  • Userport Conversations: List or search a workspace's conversations, one view at a time. Returns a short summary per thread — who wrote, the subject, a preview, whether it is unread and whether it is s
  • Userport Conversation: Read one conversation end to end: the contact, every message as plain text with markup stripped, and whether a reply can be delivered right now. Read this before replying — the

What data it sees

Do you need an account

No: the server works without sign-in

Userport is customer support and outbound messaging for SaaS founders. A chat widget on your site or app, one inbox for chat and email, a help center on your own domain, and onboarding or lifecycle messages by chat or email — all on one record per customer.

How to connect

How to connect Userport to Claude

The server address to paste into Claude settings:

https://userport--userport.run.tools

  1. Open Claude (claude.ai or the desktop app).
  2. Go to Settings → Connectors.
  3. Click Add custom connector.
  4. Paste the server address copied below into Remote MCP server URL and click Add.
  5. In a chat, click + → Connectors and switch the new connector on.

Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.

Authorization

After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.

How to connect Userport to ChatGPT

The server address to paste into ChatGPT settings:

https://userport--userport.run.tools

  1. Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
  2. Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
  3. Open Settings → Connectors and click Create.
  4. Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
  5. Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
  6. In a new chat open + → Apps/Connectors and enable the connector.

OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.

Authorization

On first use ChatGPT opens the service's sign-in window. Sign in and approve access.

How to connect Userport to Cursor

The server address to paste into Cursor settings:

https://userport--userport.run.tools

Fastest: click Open in Cursor below and confirm the prompt.

Manually:

  1. In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
  2. Paste the JSON copied below into ~/.cursor/mcp.json (per project: .cursor/mcp.json in the repo root).
  3. Save the file. The server appears in the MCP list; authorize it there if asked.

Authorization

If the service needs sign-in, an authorize button appears next to the server in the MCP list.

Server tool list (8)

Raw names from tools/list. Only developers need these.

userport_workspacesEvery workspace this account can reach, with its handle and the current state of its inbox: how many conversations are open, unread, snoozed, closed and spam, plus how email is set up. Call this first — every other tool takes a workspace handle, and handles cannot be guessed.
userport_conversationsList or search a workspace's conversations, one view at a time. Returns a short summary per thread — who wrote, the subject, a preview, whether it is unread and whether it is still `awaiting_reply` — plus the count in every view. `awaiting_reply` is the triage field: a thread can be open because nobody closed it and still have been answered. Search covers subjects, the last message preview, and contact names and addresses, not full message bodies. Page with the returned `cursor`.
userport_conversationRead one conversation end to end: the contact, every message as plain text with markup stripped, and whether a reply can be delivered right now. Read this before replying — the list only carries a preview. Messages come newest last; page backwards with `before` when `has_more` is true. A body cut to fit is flagged `truncated`.
userport_outboundRead a workspace's outbound: `view=sequences` (multi-step drips), `view=messages` (standalone one-off sends), or `view=options` (what can be targeted, written and waited on). Without `id` each view is a list; with `id` it returns that one in full, in the same shape userport_outbound_manage takes back — so reading, editing the array and sending it is the way to change a sequence. Bodies are a 160-character preview unless you pass `include=content`, which returns them verbatim for editing. **Call `view=options` before composing any audience rule**: property slugs, tag ids and subscription ids are per-account and a rule built on a guessed slug validates and then matches nobody.
userport_outbound_reportResults for one sequence, one standalone message, or the whole workspace, optionally between `since` and `until`. `detail=overview` is who entered, completed, exited and converted plus 30-day deliverability; `detail=steps` is the per-step funnel — reached, sent, delivered, opened, clicked, replied, skipped and where people dropped; `deliveries` and `events` are the raw rows. `preflight` is what a sequence must fix before it can go live and `simulate` walks one contact through it — both write nothing. Counts are distinct people; `rate_basis` says which denominator a rate used (`delivered` on email, `sent` on chat, which has no provider acknowledgement); `ctor` is click-to-open, not clicks over sends. Enrollment counts are lifetime even inside a range — a cursor has no history.
userport_replySend a message to a customer — either into an existing conversation (`conversation`) or as a new email thread to an address (`email` + `subject`). THIS SENDS IMMEDIATELY: there is no draft, no outbox and no undo, and the recipient is a real person. Read the thread with userport_conversation first, check `can_reply`, and only send text the operator has seen and approved. Requires the write permission. Pass close:true to file the thread once answered.
userport_conversation_stateClose, reopen, snooze, flag as spam, or mark a conversation read or unread. Requires the write permission. Closing is the normal end of an answered thread — it reopens by itself if the contact writes back. Nothing here sends anything to the customer; use userport_reply for that.
userport_outbound_manageAuthor outbound. `action=save` writes a whole document — with `id` it replaces that sequence or message, without one it creates a draft; read it back from userport_outbound first and edit the array you were given, because a save replaces everything and a step missing from `steps` is retired with everyone waiting at it re-pointed. Step identity is `node_id`, never position. Send `contents` (a list of {locale, subject, body, format}), never `content`. `action=state` moves draft/paused → live → paused → stopped; going live needs the preflight clean, every warning listed in `acknowledged`, and the sequence's exact name in `confirm_name`. `action=test` sends one step to your own verified address and nowhere else. `duplicate` and `delete` do what they say. `action=cancel` stops the chat→email fallbacks already queued but not yet sent — pausing or stopping does not, because those are state and this is mail waiting out its five minutes. **Saving never sends anything** — only state=live does.