Turn feature requests into specs for Claude Code and Cursor with MCP

Coding agents do well with a clear spec and poorly when they have to guess what users meant. The guessing usually comes from a context gap: the request lives in your feedback tool, and the code lives in your editor.

What is MCP?

MCP, the Model Context Protocol, is an open protocol for connecting AI apps to tools and data. An MCP server exposes a set of tools, each with a name, a description and typed inputs. A client such as Claude Code or Cursor discovers those tools and lets the model call them while it works. Servers can run locally or remotely over HTTP, and remote servers usually authenticate with a token. Clients typically ask before running a tool.

For feedback, the agent can then read a request, its quotes and its status directly instead of you pasting them in.

What makes a feature request a good spec for an agent?

A raw request ("export pls") isn't a spec. Before an agent writes code, it needs:

• The problem, in the user's terms
• Real user quotes, verbatim, so intent isn't lost in a summary
• Acceptance criteria that can be checked
• Out of scope, so the change stays small

Here's an example for a fictional habit-tracker app:

Problem: Users want their history outside the app, for spreadsheets and backups. Quotes: @mira: "I track habits for a study and need the raw data." @jonas: "I just want a backup before switching phones." Acceptance criteria: Export in Settings produces a CSV with one row per check-in; columns are habit, date (ISO 8601) and note; archived habits are included; an account with no data gets a file with headers only. Out of scope: Import, scheduled exports.

How do you connect a feedback tool to Claude Code or Cursor?

1. Create a token in your feedback tool, scoped to one project if possible.
2. Add the server to your client. In Claude Code, claude mcp add registers a server; for a remote HTTP server you pass --transport http, a name, the URL and an Authorization header. In Cursor, add the same URL and header in its MCP settings.
3. Check the connection. Run claude mcp list in Claude Code, or open Cursor's MCP settings, and confirm the server's tools show up.
4. Keep the token out of git, including shared project configs.

What does the agent workflow look like?

1. List the top requests. Ask for the most-voted open requests and pick one.
2. Fetch the spec for the chosen request.
3. Plan, then implement. Have the agent propose a plan against the acceptance criteria, approve it, then let it write code and tests on a branch.
4. Review and merge as you would any pull request.
5. Mark the request shipped once it's deployed, not when the branch merges.
6. Draft the changelog entry, edit it, then publish. The guide to writing a changelog people read and the release notes writer help here.

A prompt that sets the boundaries:

"List the top five open feature requests. When I pick one, fetch its spec, propose a plan that meets each acceptance criterion, and wait for my OK before writing code."

What should stay human?

• Choosing what to build. Votes are one input; strategy, effort and revenue are others. See how to prioritize feature requests.
• Approving plans and code.
• Anything users see. Status changes and changelog posts can notify voters, so a person should confirm them, and only once the change is live. See how to close the feedback loop.

What are the risks?

• Prompt injection. Feature requests are user-written text, and a request can contain instructions aimed at the agent. Treat it as untrusted input, keep approval prompts on for tools that write or publish, and don't give the agent secrets it doesn't need.
• Scope creep. Agents tend to do extra. Acceptance criteria and an out-of-scope list keep changes reviewable.

Doing this with Sikia

Sikia has an MCP server over Streamable HTTP at /api/mcp, with a bearer token per project, and it works with Claude Code, Cursor and other MCP clients. In Claude Code:

claude mcp add --transport http sikia https://sikia.dev/api/mcp --header "Authorization: Bearer sikia_mcp_…"

Its tools are top_requests, search, create_item, merge, get_spec, update_status and publish_changelog, and get_spec returns the problem, user quotes and acceptance criteria. The workflow above becomes top_requests → get_spec → implement → update_status → publish_changelog. Setting a request to shipped with update_status replies in its original Slack or Discord threads and adds it to the changelog draft, and publish_changelog emails everyone who voted for the requests it ships.

FAQ

Do I need MCP, or can I paste the request into the chat?

Pasting works for a single request. MCP helps when you want the agent to search, pull quotes and update status without you copying data between tools.

Does this work with Cursor and other editors?

Any MCP client that supports remote HTTP servers can connect. Setup differs by client, but it comes down to the server URL plus an authorization header.

Can the agent decide what to build on its own?

It can rank requests by votes, but votes aren't a roadmap. Keep the choice, and the final review, with a person.