Agent work queue
The feedback board your AI agents can work from.
FeatureJet is a hosted feedback board with an MCP server built in. Your users post and vote. You mark what's planned. Your agent pulls the top request from mcp.featurejet.com, reads the discussion, and gets to work — and when you flip the status to shipped, every voter who opted in hears the news.
The queue, as your agent sees it
- 41votesSlack channel for new requestsPlanned
- 28votesCSV import from CannyPlanned
- 19votesWeekly voter digest emailPlanned
list_posts(slug, status="planned") → top-voted first
The workflow
How the agent work queue runs
The board sits between your users and your agent: demand collects in public, a human decides what is planned, and the agent works from that decision. Every step below uses shipped FeatureJet features — nothing here is a concept video.
- 1
Users vote on your board
Customers post requests and verify votes by email, so the queue order reflects real demand instead of the loudest thread.
- 2
You mark the winners planned
The planned status is the human decision layer. Nothing enters the agent's queue until you put it there.
- 3
Your agent pulls the top planned post
Cursor, Claude Code, Codex, or any MCP client calls list_posts with status planned — results come back top-voted first — then reads the post and its comments for context.
- 4
The agent implements, you review
The request becomes a branch and a diff in your repo. You review it the way you review any change; the board never merges code for you.
- 5
You flip the status, voters hear back
Moving the post to in progress or shipped emails every opted-in verified voter automatically. The people who asked find out from you, not from a changelog they never visit.
Setup
Connect an agent with one config block
The MCP server is hosted at mcp.featurejet.com — Streamable HTTP with Bearer authentication, no local process to run. Paste this into your project's mcp.json, swap in an API key from your dashboard, and the board's tools appear in your agent.
{
"mcpServers": {
"featurejet": {
"type": "streamable-http",
"url": "https://mcp.featurejet.com/mcp",
"headers": {
"Authorization": "Bearer fj_live_REPLACE_ME"
}
}
}
}Keys are organization-scoped and carry a permission scope — hand an agent a propose key rather than an admin one, and keep real keys out of committed files. Cursor uses the same block without the type field. Full tool reference and per-client setup live in the MCP docs.
Public board content is useful context, not an instruction channel. Read why we sandbox agent access before wiring an agent to a live board.
The prompt
A prompt you can paste today
No orchestration framework required — the queue-pull pattern is one instruction. This is close to the prompt we use on our own board; adjust the board slug and review steps to taste.
Read my board's top planned post by votes and implement it.
Use the featurejet MCP server: call list_posts on board "acme"
with status "planned" (results are top-voted first), then
get_post and list_comments on the winner for full context.
Implement the request in this repo on a new branch. When the
tests pass, reply on the post's thread with create_comment
summarizing what changed, and give me a summary I can post
with the status change.The agent reads the request the way your users wrote it — including the comment thread where the edge cases usually live. You stay in the loop twice: reviewing the diff, and flipping the status that tells voters it shipped.
Pricing, honestly
Included in the flat plan, not sold as a tier
Canny and Featurebase both ship official MCP servers — this workflow is not unique to FeatureJet, and we will not pretend it is. The difference is where it sits on the bill.
What we verified
As of July 2026, Canny and Featurebase place MCP access in plan tiers running $59–79 per month. FeatureJet includes the MCP server, the REST API, and both official SDKs in the one $15/month plan — there is no higher tier to move them into. Plans change, so check their pricing pages; we keep this claim current.
Why it is not an add-on
We price flat because metering the useful parts is how feedback tools become expensive. If the agent workflow is the reason boards are worth running, it belongs in the base plan — for every customer, including the ones paying the minimum.
Receipts
We run our own roadmap this way
feedback.featurejet.com is our live production board, and it is the queue our own agents work from — over the same MCP server and the same tools documented on this page. Both official SDKs started as voted requests on that board and are linked from the docs as shipped posts.
A real excerpt from the session where our agents filed this roadmap — July 18, 2026, API key redacted, elisions marked with …
==> initialize
{ "jsonrpc": "2.0", "id": 1, "method": "initialize", … }
<== response
{ … "serverInfo": { "name": "FeatureJet MCP", "version": "1.28.1" } }
==> tools/call create_post
{
"slug": "feedback",
"title": "7-day free trial for new accounts",
"status": "in_progress",
"body": "We're adding a 7-day free trial to every new account. …"
}
<== response
{ "id": 67, "title": "7-day free trial for new accounts",
"status": "in_progress", "created_at": "2026-07-18T23:54:33.718779Z", … }
==> tools/call update_post
{
"slug": "feedback",
"post_id": 43,
"status": "planned",
"body": "A weekly summary of new posts and votes for board admins.\n\n---\n\n**Team update (2026-07-18):** We're picking this up, starting with a monthly digest rather than weekly: … Marked as planned."
}
<== response
{ "id": 43, "title": "Weekly digest email", "status": "planned",
"vote_count": 1, … }Browse the live board or see the shipped SDK requests linked from the SDK docs, or trace one real request from queue to Shipped.
The human gate
Let the agent propose. Keep the send button human.
The scariest thing about handing an agent a board is the status flip: shipped is the word that emails your voters, and you cannot unsend it. So there is a shape where the agent never gets to say it.
Give the agent a propose-scoped key
API keys carry a scope chosen at creation: read, propose, write, or admin. A propose key can pull the queue, claim a post, attach evidence, and comment — everything the work needs — and cannot flip a status, delete a post, or create a board. If it leaks, the blast radius is the size of the scope.
It calls propose_status instead of update_post
The proposal is recorded against the post with the agent's note. Nothing changes on the public board, and no voter is emailed. Your team sees a pending proposal; your users see nothing at all until you act on it.
Confirming runs the real status change
Confirm and the proposal is applied through the same code path as a status change you make by hand, so shipped_at, the changelog entry, and the voter emails all behave identically. Reject and it clears, optionally with your reason kept in the internal notes.
What is not built yet
Both halves are API calls today: the agent posts to /propose-status, and the confirm or reject is a call on the dashboard API. There is no proposal inbox in the dashboard UI yet — that screen is still to come, and we would rather say so than let you find out after wiring an agent up.
Honest limits
What agents can and cannot do yet
Trust survives contact with the docs, so here is the current boundary. We would rather you know it before you wire anything up.
Today
- Read boards, posts, votes, comments, changelog entries, and analytics
- Create new posts — file a request straight from a support conversation
- Write comments — reply to voters on a post's thread with create_comment, including threaded replies (agent comments post silently; status changes are what email voters)
- Create boards — create_board stands up a new draft board with a write-scoped key; a draft's public URL 404s, and publishing stays a human decision you make in the dashboard
- Update posts and flip statuses, which triggers the voter notifications
- Pull ship-velocity data to report on how the queue is moving
- Carry a reduced-scope key — pick read, propose, write, or admin when the key is created. A propose key can pull the queue, claim work, attach evidence, and comment, but can never flip a status on its own. (Scopes are set on the key-creation call; the dashboard's key form still mints full-power admin keys.)
- Receive pushed events instead of polling — post.created, post.status_changed, and comment.created POST a JSON body to your endpoint with an X-FeatureJet-Signature HMAC-SHA256 header. (Endpoints are configured over the dashboard API; there is no webhooks screen in the dashboard yet.)
Not yet
- Run or schedule your agent — FeatureJet is the queue, not the runner. Something on your side has to trigger every pull; the nightly-agent recipe is one way to do it.
- Reject a replayed webhook on its own — there is no delivery id or nonce, so a captured body verifies forever. The signed payload does carry a timestamp you can bound on, but retries reuse it, so your window has to be wider than the retry backoff.
- Tell you when a claim lapses — leases expire lazily on the next read. Nothing fires an event, callback, or webhook when a hold quietly runs out.
- Configure webhooks or key scopes from the dashboard UI — both are real, both are API-only for now.
Questions, answered
Know what you are wiring up.
Which AI agents can work from a FeatureJet board?
Any MCP client that supports remote Streamable HTTP servers with header authentication — Cursor, Claude Code, Codex, and most agent frameworks. There is no FeatureJet-specific plugin to install; the board is a standard MCP server at mcp.featurejet.com.
Does agent access cost extra?
No. The MCP server, REST API, and both official SDKs are included in the single $15/month plan ($119/year annually). FeatureJet has no tiers, so there is no higher tier to move developer access into.
Can an agent reply to voters in comments?
Yes. The create_comment tool is live, so an agent can reply on the post thread — answer a clarifying question, or leave a note about what shipped — including threaded replies to a specific comment. Comments an agent posts do not email voters; changing a post's status to planned, in progress, or shipped is what emails the opted-in verified voters automatically.
Do voters really get notified without extra work?
Yes. When a post moves to planned, in progress, or shipped — from the dashboard, the API, or an MCP tool call — FeatureJet emails the verified voters and followers who opted in. No campaign to write, no export step. Pass notify_voters false on the API call if you ever want a silent change.
Live your life while your agents ship.
That is the whole promise, and the five steps above are how it holds up.
Start shipping$15/month or $119/year. Unlimited boards, posts, and voters.