Connect an AI assistant to your feedback loop

Connect your agent in 60 seconds

1. 1. Create an API key

   Dashboard → API keys → name it → Create key. The key is shown once with a copy button, so copy it before you leave the page.

2. 2. Paste one block

   For Claude Code this is the whole setup — the first line sets your key, the second registers the board:

   Claude Code — terminal

   export FEATUREJET_API_KEY="fj_live_PASTE_YOUR_KEY"
   claude mcp add-json featurejet "{\"type\":\"http\",\"url\":\"https://mcp.featurejet.com/mcp\",\"headers\":{\"Authorization\":\"Bearer $FEATUREJET_API_KEY\"}}"

   Prefer a committed project file? Put this in .mcp.json instead — Claude Code expands the variable from your environment, so add the export to your shell profile and the key stays out of the repo:

   .mcp.json

   {
     "mcpServers": {
       "featurejet": {
         "type": "streamable-http",
         "url": "https://mcp.featurejet.com/mcp",
         "headers": {
           "Authorization": "Bearer ${FEATUREJET_API_KEY}"
         }
       }
     }
   }

   Using Cursor or Codex? Same endpoint, same key — their config blocks are in the reference sections below.

3. 3. Ask for the queue

   First prompt

   Read my board's top planned post

   That first run is read-only, so nothing on your board changes: your agent lists the planned requests, top-voted first, and tells you what your users want next. Everything past this point — creating posts, flipping statuses, working the queue unattended — is covered below.

Endpoint and auth

https://mcp.featurejet.com/mcp

Authorization: Bearer fj_live_REPLACE_ME

Keys are per organization and scoped to that organization. Unknown and cross-org boards or posts behave like the API and return not found. Keep real keys out of committed config files, public terminals, and shared shell history.

Wire up your agent

Point your agent at the queue — Cursor, Claude Code, Codex, any MCP client — and it can work your planned requests without you in the room. Every recipe below is the same two facts in a different file format: the hosted endpoint and your API key.

Claude Code

claude mcp add-json featurejet '{"type":"http","url":"https://mcp.featurejet.com/mcp","headers":{"Authorization":"Bearer fj_live_REPLACE_ME"}}'

{
  "mcpServers": {
    "featurejet": {
      "type": "streamable-http",
      "url": "https://mcp.featurejet.com/mcp",
      "headers": {
        "Authorization": "Bearer ${FEATUREJET_API_KEY}"
      }
    }
  }
}

A project-scoped .mcp.json usually gets committed, so reference the key through Claude Code's environment-variable expansion as shown instead of pasting it. The type field is required — Claude Code reads an entry with a url but no type as a local stdio server.

Cursor

Put this in .cursor/mcp.json in your project, or in ~/.cursor/mcp.json to make the board available everywhere. Cursor infers the transport from the url and expands env: references, so the key stays out of the file.

{
  "mcpServers": {
    "featurejet": {
      "url": "https://mcp.featurejet.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:FEATUREJET_API_KEY}"
      }
    }
  }
}

Codex

Codex configures MCP servers in ~/.codex/config.toml. A url means Streamable HTTP, and bearer_token_env_var names the environment variable holding your key — Codex sends it as the Authorization bearer header.

[mcp_servers.featurejet]
url = "https://mcp.featurejet.com/mcp"
bearer_token_env_var = "FEATUREJET_API_KEY"

The queue-pull prompt

The pattern that turns the board into a work queue is one instruction: list_posts with status planned returns results top-voted first, so the next thing to build is a single tool call. 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, comment thread included — and with create_comment it can reply on the thread, answering a clarifying question or noting what shipped. Agent comments post silently; it is the status flip with update_post that emails the opted-in verified voters and followers automatically.

Running it unattended

FeatureJet does not run or schedule your agent — the board is the queue, and something on your side does the pulling. Run the prompt above on whatever cadence you already trust: a cron or launchd job that starts your agent's non-interactive mode, a scheduled CI workflow, or your agent platform's own scheduler. Each run pulls the current top planned post, so the queue reorders itself as votes land between runs.

If you would rather copy a scheduler than write one, ours is published: the nightly agent recipe is a complete GitHub Actions workflow that wakes at 02:17, pulls one item with get_queue, and saves the resulting diff as an artifact for you to read. It lives on your side of the line by construction — you copy it into the repository the agent should change, and GitHub Actions, not FeatureJet, is what runs it.

Keep the human review step. The agent leaves a branch and a diff; you review it, merge it, and flip the status — and the status flip is what tells your voters it shipped. The full workflow, including what agents can and cannot do yet, is on the agent work queue page.