MCP server

The endpoint, connecting an editor to it, how the OAuth consent works, and the three tools your agent gets.

The endpoint

Every project has its own MCP endpoint. It is on the project's MCP tab, and it looks like this:

https://userwants.app/api/mcp/your-project-slug

The project lives in the URL rather than in the credential, so the tools take no project argument and your agent cannot address a project it was not given.

Connecting

The configuration is the URL and nothing else — there is no token to create, reveal or revoke, so the snippet is safe to commit:

{
  "mcpServers": {
    "userwants": {
      "type": "http",
      "url": "https://userwants.app/api/mcp/your-project-slug"
    }
  }
}

What differs between editors is which file reads it:

• Claude Code — .mcp.json in the project root, or run claude mcp add --transport http userwants https://userwants.app/api/mcp/your-project-slug.
• Cursor — .cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project.
• VS Code and Zed both speak HTTP MCP and take the same URL, but each nests it under its own key. Check your editor's MCP documentation for the exact shape; the URL above is the only part that comes from UserWants.

How access works

The first time your editor connects it opens a browser and asks you to approve it. From then on the agent acts as you: it sees the project because you are a member of it, and it can change a report's status only if your role already allows it — the same rule the admin panel applies.

That has one consequence worth knowing: set_bug_status is only registered for owners and admins. If your role is member, the tool is not missing or broken — it was never offered, so your agent never plans around something it would be refused.

The plan that counts is the project owner's, not yours. Inside the owner's free report allowance everything here works. Past it, the tools still answer — they list and read the reports the owner can read, and say how many are locked and where to upgrade.

The three tools

list_bugs — reports, newest first, defaulting to bugs. Filters: type (bug, feedback, all), status, since (7d, 24h, 30m or an ISO date), q for free text over title and description, and limit (up to 50). Each row is one line: ref, type, status, age, title, and the first JavaScript error if one was captured.

get_bug — one whole report from its ref: description, who sent it, the page they were on, browser and viewport, the JavaScript errors with stack traces, the numbered steps they took, and a link to the screenshot. Set include_screenshot: true to pull the image into the conversation as well — it costs a lot of context, and the link in the text is usually enough.

set_bug_status — moves a report through pending, planned, in_progress, completed, rejected. Emailing the reporter is off unless you ask for it: sending mail to someone else's user is not a side effect anyone should get by accident.

There is also a triage_bugs prompt, which shows up as a slash command in editors that support them.

Refs

Reports are addressed by an 8-character hexadecimal ref, the front of the report id. A shorter prefix works as long as it is at least four characters and matches exactly one report; if it matches several, the tool answers with the candidates rather than guessing.

Rate limits

300 calls per hour per person, and 600 per hour per project. Generous on purpose — an agent working through a list in a burst is the intended use.