Your AI agent can read every file in your repository. It knows your schema, your route handlers, the half-finished migration you left in alembic/versions
. Ask it how to build almost anything and it will tell you.
Ask it what to build and it has nothing.
That asymmetry bothered me for months. I'd be in Claude Code planning a sprint, and the actual demand signal , what users were asking for, how many wanted it, and crucially why was sitting in a browser tab the agent couldn't see. So I'd alt-tab, skim the board, mentally rank things, come back, and re-type the conclusion as a prompt. Every single time.
I run a feedback board product, so the fix was obvious in retrospect: expose the board over MCP. This post is about the design decisions that turned out to matter, because most of them weren't obvious going in.
The board already had a REST API. That was my first instinct: document it, tell people to write a script.
But a REST API is built for programs you write. MCP is built for agents you talk to. The difference isn't the transport , it's who does the integration work.
With REST, you decide which endpoints to call, in what order, and write the glue. With MCP, the agent discovers the tools, reads their descriptions, and chains them itself. "Find the top request, read its comments, draft a spec" is one sentence to an agent with MCP access. With a REST API it's an afternoon.
That's the whole pitch. If your product has data an agent could reason over, MCP is not "REST with extra steps" — it's the difference between an integration you build and one that assembles itself.
This was the decision I spent the most time on, and it's where I'd push back on how a lot of MCP servers are being built right now.
The temptation is to expose everything. You already have the endpoints; mapping them one-to-one into MCP tools feels like free surface area. Resist it. Every tool you expose is:
I landed on seven tools.
Read (five):
| Tool | What it does |
|---|---|
list_boards |
|
| Every board in the workspace, with post counts | |
list_posts |
|
| Posts, filterable by board/status, sortable by votes or recency | |
get_post |
|
| One request in full — body, status, votes, entire comment thread | |
get_roadmap |
|
| Planned / in progress / completed, as data | |
get_changelog |
|
| Published entries, so the agent knows what already shipped |
Write (two):
| Tool | What it does |
|---|---|
create_post |
|
| File a new request — e.g. one that arrived by email | |
update_post_status |
|
| Move a request through the lifecycle |
That's it. No tools for billing, no team management, no workspace administration. A token grants access to exactly one workspace's feedback data and nothing else.
The read/write asymmetry is deliberate. Five read tools give the agent everything it needs to understand the board. Two write tools let it act — and both actions are cheap to reverse. Nothing an agent can do through this server is destructive.
update_post_status
is the interesting one, because it has a side effect: moving a request to completed emails everyone who voted for it. That's not a hidden gotcha, it's the point — but it did make me think hard about whether an agent should be able to trigger outbound email at all. I kept it because the loop is the whole value: users learn that asking works, so they keep asking, so the signal improves. Breaking that loop to be cautious would have made the integration pointless.
One token, one workspace, revocable instantly from settings. Bearer auth over streamable HTTP. No OAuth dance.
I got asked early whether the server should support a "read everything across all your workspaces" token for people running multiple products. No. The convenience is real and the failure mode is bad — a leaked token that reaches one board is an annoyance, one that reaches all of them is an incident. Multi-workspace users generate multiple tokens. It's mildly worse UX for a materially better security story.
The general principle I'd offer: when you're deciding what an MCP token can reach, imagine the token in a public GitHub commit, because eventually one will be. Design for that, not for the happy path.
Claude Code:
claude mcp add --transport http featurewish \
https://app.featurewish.com/mcp \
--header "Authorization: Bearer fw_mcp_YOUR_TOKEN"
Cursor, in .cursor/mcp.json
:
{
"mcpServers": {
"featurewish": {
"url": "https://app.featurewish.com/mcp",
"headers": {
"Authorization": "Bearer fw_mcp_YOUR_TOKEN"
}
}
}
}
Claude Desktop and Claude.ai take it as a custom connector — endpoint URL plus the token as a bearer header. The client discovers the seven tools on first connect.
No SDK. That's a feature of MCP generally, not of my implementation, but it's worth stating plainly because "integration" usually means a package and a config file and a webhook receiver.
The honest answer is that it collapsed a context switch I didn't realize was expensive.
Things I now say mid-session instead of alt-tabbing:
What are the ten most-voted open requests right now?
Read the comments on the CSV export request and summarize what people actually need — not what they're asking for, what they need.
Which planned roadmap items have the fewest votes? Should any be demoted?
A customer emailed asking for SSO. File it on the Features board with their reasoning.
We just shipped dark mode. Mark that request completed.
That third one turned out to be the sleeper. Roadmaps accumulate items you committed to when three people asked and then never revisited. Having an agent that can cross-reference stated plans against current demand, on request, is a genuinely different relationship with your own roadmap than opening the board and feeling vaguely guilty.
The second one matters too, for a reason specific to feedback: the comment thread is where the actual requirement lives. The request title is "add CSV export." The comments are where you learn three people need it scheduled, one needs a specific column order, and one is actually describing a reporting problem that CSV export won't solve. That's a lot of reading. It's a good summarization task.
Four things I'd do again:
And one I'd do differently: I built the read tools first and shipped them, then added writes. That was right. If I'd designed all seven upfront I'd have over-fitted the write side to guesses about usage instead of to what people actually asked for once reads were live.
I build FeatureWish, a feedback board for indie SaaS — feature requests, voting, roadmap, changelog. The MCP server is on the paid tier; the board itself is free forever. The scoping decisions above apply to any MCP server, though — take them and build your own.
This article was created with the help of AI