MCP

PM Copilot: cross-check tickets and requests before deciding what to do

For product managers who want to cross-check HelpScout tickets with optional requests and chats before deciding next steps, provided they build locally, call synthesize_feedback, and configure HelpScout first.

Official source · PM Copilot

Install

git clone https://github.com/dkships/pm-copilot.git
cd pm-copilot
npm install
cp .env.example .env
npm run build

Who it is for

If you are a product manager and want to line up customer-support tickets, feature requests, and AI support chats before deciding what to do next, this service matches. Official docs call it an MCP server for triangulation.

It fits people who can clone the repository locally, run the build with node, and already hold HelpScout credentials. HelpScout is required. ProductLift and Chatbase are both optional: configure one, both, or neither, and the analysis changes with that. Without HelpScout, official docs give no usable path.

Analysis touches customer source text. Official docs say SSNs, credit-card numbers that pass a Luhn check, emails, and phone numbers are redacted before analysis, and agent replies are filtered out of quotes. This is not zero risk: ticket subjects still enter the analysis.

First try in 3 minutes

The official recommended path is to clone and build locally. Prerequisite: have HelpScout credentials ready.

Follow the official steps:

git clone https://github.com/dkships/pm-copilot.git
cd pm-copilot
npm install
cp .env.example .env
npm run build

After copying the environment-variable template, fill in your real credentials. Official docs only write Edit with your credentials and do not list variable names; do not invent key names, only change items already in the template. After the build, in the MCP client set command to node and point args at dist/index.js in your local repository. The official example uses an absolute-path placeholder; change it to the real path after your clone, and do not copy the placeholder directory. Save, reload, and confirm the service is connected.

Then make one call: call synthesize_feedback. Official docs say it cross-checks HelpScout tickets, ProductLift feature requests, and Chatbase conversations, and returns theme-matched analysis with priority scores. Parameter fields are not written; call it according to the definition the client shows. The first time you can configure only HelpScout and leave the other two unconfigured.

Success signal: analysis comes back with themes and priority scores. If you get a credential error, first check that .env was filled for HelpScout from the template, not left as an empty file.

Usage examples

Example 1: theme analysis with HelpScout only. Call synthesize_feedback. Official docs say the other two sources are optional and the analysis adapts. Ticket time range and email filters are not written. On success you should see theme matches and priority scores. Do not treat the scores as a finished roadmap.

Example 2: with HelpScout already in place, add ProductLift or Chatbase, or both, and call synthesize_feedback again. Official docs say it cross-checks these three source types. Weights between sources are not written. On success you should see theme analysis that also counts requests or conversations. Quotes should not contain unfiltered agent wording, but do not assume all PII has been removed.

Limits

HelpScout is required; ProductLift and Chatbase are optional. Customer data enters the analysis; only the PII types official docs name are redacted first. Queries go online to those services.

Official docs write neither a rate limit nor undo. Analysis results are not a shipping decision. This page names only synthesize_feedback; do not invent other planning tool names. dist/index.js in the config must point at the artifact you built locally.