You build with an agent now. Your feedback board should too.

Something quietly shifted in how software gets built. A small team in 2026 doesn't hand-write most of its code — it directs agents that do. The agent reads the whole repository, plans the change, writes it, tests it. The "how" of building has never been cheaper.

Which moves the whole game to the "what." When implementation is fast, the expensive mistake isn't a bug — it's spending your agent-accelerated week building the wrong thing. And here's the asymmetry almost nobody has fixed: your agent knows everything about your code and nothing about your users. It can refactor your billing module blindfolded, but ask it "should I build CSV export or SSO first?" and it can only guess, because the demand signal — the requests, the votes, the frustrated comment threads — lives in tools it can't see.

FeatureWish fixes that with a built-in MCP server. Your feedback board becomes something your agent can query mid-conversation, the same way it reads a file. This page is about what that actually changes day to day — the concrete workflows, with the prompts that drive them.

The context problem, stated plainly

An AI agent is only as good as the context it can reach. That's why agents got dramatically more useful when they could read your codebase, run your tests, and search the web: each new surface removed a category of guessing.

But product decisions don't live in the codebase. They live in what users ask for, how many of them ask, how they phrase the pain, and what they say in the comments when you ask "what are you actually trying to do?" If that signal is scattered across DMs, support email, and memory, it's invisible to your agent — and honestly, mostly invisible to you.

A feedback board already solves the human half of that: one front door where requests land, votes stack, and duplicates merge. Making the board agent-readable solves the other half. Now the single source of truth about demand is available to the thing that does your building — and "what should we build next?" becomes a question with data behind it, asked and answered in the same window where the building happens.

Five workflows that change

1. Morning triage in one prompt

Triage is the chore that kills feedback boards: new posts pile up, duplicates scatter votes, and after two skipped weeks the board stops being trustworthy. With the board connected, triage becomes a standing prompt:

"Check my feedback board. Summarize anything new since Monday, flag posts that look like duplicates of existing requests, and tell me if anything planned is getting unusual vote velocity."

The agent lists boards, pulls recent posts, compares titles and bodies against what's already there, and hands you a two-minute digest instead of a twenty-minute click-through. You still make the calls — merge this, ignore that — but the reading is done for you. (FeatureWish also surfaces duplicate suggestions to your users as they type, so much of the mess never lands in the first place.)

2. "What should I build next?" — with receipts

This is the flagship workflow, because it combines the two things your agent can now see: demand and effort. Your board knows what users want; your codebase knows what's cheap to build. An agent connected to both can do the cross-reference no dashboard ever could:

"Look at the top ten most-voted open requests on my board. For each one, skim the codebase and estimate rough effort. Which three have the best votes-to-effort ratio?"

That prompt used to be a planning afternoon: export the board, guess at effort, argue with yourself. Now it's a coffee break — and the answer comes with reasoning you can interrogate ("why do you think SSO is a week?") instead of a gut feeling you can't.

3. Specs drafted from real user threads

The comments under a popular request are the best spec material you own: actual users describing actual situations, edge cases you'd never invent, and the exact vocabulary your audience uses. Most founders never mine it. An agent can:

"Read the 'CSV export' request and its full comment thread. Draft an implementation plan: what people actually need, what's explicitly out of scope, and the acceptance criteria hiding in those comments."

The agent pulls the post and every comment through get_post, and the spec it drafts is grounded in what fourteen real people said — not in what you remember them saying. Then, because it's the same agent, it can start building against that spec in the next message.

4. Closing the loop without leaving your editor

The whole reason feedback boards compound is the loop: users see that asking works, so they keep asking, and your signal improves. The loop's weak point has always been the last step — you ship the thing, then forget to tell anyone. Connected to the board, your agent finishes the job as part of shipping:

"We just merged dark mode. Mark the request completed on the board, and draft a changelog entry from the PR description."

update_post_status flips the request to Completed — which automatically emails everyone who voted, because that notification loop is built into FeatureWish. Every voter learns their wish shipped, minutes after the merge, without you opening a browser tab. That's the trust-building moment most products miss, reduced to a sentence.

5. One front door for feedback from anywhere

Feedback doesn't arrive politely on the board. It arrives in support email, DMs, sales calls, and app-store reviews. The habit that keeps a board honest — "log everything where the votes are" — becomes trivial when your agent holds the pen:

"A customer emailed this: [paste]. If there's an existing request for it, tell me so I can point them at it. If not, file it on the Features board with their use case as the body."

The agent checks for duplicates first (so votes concentrate instead of scattering), then files with create_post. Six months of doing this and your board is a complete, deduplicated record of everything anyone ever asked for — which makes every other workflow on this page smarter.

Why we built it as MCP, not a bespoke AI feature

A lot of feedback tools are answering the AI moment by bolting a chatbot onto their dashboard. We think that's backwards. You already have an agent — one that knows your codebase, your style, and your history. You don't need our AI; you need your AI to see your feedback.

That's what the MCP server is: an open-standard endpoint (Model Context Protocol — the same protocol Claude, Codex, Cursor, and a fast-growing list of clients speak natively) that exposes seven carefully-scoped tools. Five read (boards, posts, post detail with comments, roadmap, changelog), two write (create a post, update a status). Setup is a URL and a bearer token from Settings → MCP — no SDK, no webhook infrastructure, revocable any time.

The scoping is deliberate. Your agent can work the feedback — it can't touch billing, team members, or anything outside the workspace the token belongs to. And there's no autonomous black box deciding your roadmap: the agent reads, summarizes, drafts, and files, but the judgment stays where it belongs. With you.

Where this is heading

We think agent-readable is becoming table stakes for founder tools, the way an API was a decade ago — and the tools that win will be the ones that were designed for it rather than retrofitted. Discovery is changing the same way: founders increasingly ask their assistant "what's a good feedback tool?" instead of a search box, which is why FeatureWish's public portals are server-rendered and crawlable, and why both our domains ship an llms.txt. Your public board is legible to the next generation of readers, human or not.

Getting started

1. Create your board free. The core loop — boards, voting, roadmap, changelog, widget — is free forever, with unlimited tracked users and teammates. Start collecting real signal.
2. Upgrade to Pro when you want the agent in the loop. The MCP server is part of Pro — $20/month flat, never metered, alongside five workspaces with ten boards each, GitHub/Linear integrations, custom CSS, and white-labeling.
3. Generate a token and connect. Settings → MCP, one token, paste into Claude Code, Claude Desktop, Codex CLI, or Cursor. Copy-paste setup snippets are here.
4. Steal the prompts above. Start with morning triage; the rest follows naturally the first time you ask "what should I build next?" and get an answer with receipts.