Triage feature requests from inside Cursor with MCP

I build in Cursor. Feature requests live on a board in another tab. This is how I connect the two — and what that does not do.

The honest problem with feedback tools is not collecting requests. Any form can do that. The problem is that the requests sit in a dashboard while I sit in my editor, and the two only meet when I feel guilty enough to go look.

For a solo developer that gap is expensive. A request with twelve votes waits weeks while I build something nobody asked for.

What I actually wanted

Three things:

1. A widget in my app so users can send a feature request or a bug without emailing me.
2. Those requests landing on the same board as my public roadmap and changelog — not in a separate tool.
3. A way to read, sort and answer them from the editor where I already am.

The first two have been in Pullwish for a while. The third is what MCP (Model Context Protocol) made possible.

Step 1: collect requests with the widget

featurely-feature-reporter is a small embeddable widget. Users get a feature request form and a bug report form, with screenshot capture, and submissions go straight to your board.

import { FeatureReporter } from 'featurely-feature-reporter';

const reporter = new FeatureReporter({
  apiKey: process.env.NEXT_PUBLIC_FEATURELY_API_KEY!,
  projectId: process.env.NEXT_PUBLIC_FEATURELY_PROJECT_ID!,
  position: 'bottom-right',
  color: 'blue',
});

reporter.init();
reporter.setUser(user.id, user.email, user.name);

setUser matters more than it looks. When I know who asked, I can answer them, and I can tell a paying customer's request from a drive-by one.

You can turn either form off (enableFeatureRequests, enableBugReports), change the labels, and set showDashboardLink: true to link users to the public board so they vote on existing ideas instead of posting duplicates.

Step 2: connect the board to Cursor

There are two MCP servers, and they do different jobs:

• The docs server (pullwish-mcp) gives your AI assistant the full SDK docs. It is read-only and never touches your project.
• The hosted MCP at https://www.pullwish.com/api/mcp is the one that talks to your actual board. Add this to ~/.cursor/mcp.json (or .cursor/mcp.json in the project). Cursor opens a browser sign-in — no API key:

{
  "mcpServers": {
    "pullwish": {
      "url": "https://www.pullwish.com/api/mcp"
    }
  }
}

During sign-in you choose read or write access for the projects you grant.

Step 3: triage without leaving the editor

With the hosted MCP connected, Cursor's agent can call real tools against my project. The ones I use for feature requests:

• list_features — newest requests and bugs, with a free-text search, so I can ask "anything about CSV export?"
• get_feature and get_feature_votes — the full request and how many people want it
• list_comments and post_comment — read the thread and answer as the team
• list_workflow_statuses and update_feature_status — move a request to planned or in progress, using the project's real status names instead of guessing
• publish_changelog — when it ships, write the changelog entry from the same place

The loop this makes possible: ask the agent for this week's new requests and their votes, read the top few, mark one as planned, post a short reply on the others, then start building the planned one — in the same window.

One detail I care about: update_feature_status can also set internal. Internal items are hidden from the public board, and public reads return 404 for them. So a request that contains something private can stay on my side without being deleted.

What this is not

This is not an AI that decides your roadmap. The agent reads and writes what you tell it to. I still choose what gets built.

It is also not a replacement for talking to users. MCP makes it cheaper to read and answer requests. It does not make the answers good.

And if you do not use an AI editor at all, none of step 3 matters to you. The widget, board, roadmap and changelog work fine from the dashboard.

Pricing — be honest

The free Hobby plan gives you one project with customer voting, a public roadmap, a changelog and comment threads. The widget uses an API key.

Hosted MCP reading works on every plan, including Hobby — you are only limited by how often you can call. Writing (creating items, changing status, posting comments) uses the API quota, which is 0 on Hobby, so write access needs Indie or higher (€19/month, VAT included). The 14-day Indie trial counts. Details: https://www.pullwish.com/#pricing

Why I built it this way

I did not want another tab. I wanted the requests to show up where the work happens, so the gap between "a user asked for this" and "I am building this" gets shorter.

If that is how you work too, try the live demo from the site menu — no sign-up required — or ask in the in-app chat on https://www.pullwish.com.

AI Disclaimer: The experiences and concepts shared in this article are my own. To ensure the best reading experience, I collaborated with Gemini AI to proofread my original draft, refine the sentence structure, and correct grammatical errors. No content or history was artificially generated.