Skip to content

Model Context Protocol

Your coding agent already fixed it. Let it tell your users.

FeedFast ships an MCP server, so the assistant you already code with can read your feedback board, publish the changelog, schedule maintenance and check uptime: without you leaving the editor.

Add it to any MCP client

Connect to the hosted server with a URL, or run it locally through npx. Either way, all you need is an API key.

Hosted: a URL and your key

Nothing to install and nothing to update: the server runs on ours. Works in Claude Code, Claude Desktop, Cursor, Windsurf and VS Code.

Claude Code

One command, then restart the session.

claude mcp add --transport http feedfast https://feedfa.st/api/mcp --header "Authorization: Bearer ff_your_key_here"

Claude Desktop, Cursor, Windsurf, VS Code

The same object everywhere: only the config file's location differs.

{
"mcpServers": {
"feedfast": {
"type": "http",
"url": "https://feedfa.st/api/mcp",
"headers": {
"Authorization": "Bearer ff_your_key_here"
}
}
}
}

Local: run it through npx

For clients without HTTP transport, and for when the key should stay on your machine. Fetched from npm on each run.

Claude Code

Add --scope project to commit it to the repo for your team.

claude mcp add feedfast --env FEEDFAST_API_KEY=ff_your_key_here -- npx -y feedfast-mcp

Claude Desktop, Cursor, Windsurf, Zed, VS Code, Gemini CLI

Same file as above.

{
"mcpServers": {
"feedfast": {
"command": "npx",
"args": [
"-y",
"feedfast-mcp"
],
"env": {
"FEEDFAST_API_KEY": "ff_your_key_here"
}
}
}
}

Codex

TOML, in ~/.codex/config.toml.

[mcp_servers.feedfast]
command = "npx"
args = ["-y", "feedfast-mcp"]
env = { FEEDFAST_API_KEY = "ff_your_key_here" }

The key comes from Settings → Account → API keys, and both transports take the same one. A read-only key lets an agent answer questions but never change anything. Give it a read-write key only when you want it to publish. The local form runs feedfast-mcp, fetched from npm on each run.

Works with Claude Code, Claude Desktop, Cursor, Windsurf, Zed and VS Code (Copilot agent mode): anything that speaks MCP.

The loop

FeedFast is the half your agent can't see

Your assistant can read your repo, write the fix and run your deploy. What it has no access to is what your users actually asked for, and the public record of what you shipped. That’s the gap this closes.
  1. Ask what people want

    “What are the top open bugs on my board?” The agent calls list_feedback and comes back with titles, vote counts, categories and the comment threads: the real ones, from your real users, not a guess about what might be wrong.
  2. Fix it in your editor

    This part is entirely yours. FeedFast never sees your code, your repo or your deploy pipeline. It has no access to any of them. Your assistant works exactly as it always does, with one difference: it knows which thing is worth working on, because forty people voted for it.
  3. Close the loop in one call

    resolve_feedback marks the request Done, posts a public reply with an Owner badge, and publishes a changelog entry for the fix: with the reply linking to it automatically. The person who reported it gets an answer that points at the release note.
  4. Announce the downtime before it happens

    Migration coming? schedule_maintenance takes a wall-clock time and a timezone. During the window FeedFast opens no incidents and sends no down-alerts, the status page reads “under maintenance” instead of red, and uptime percentages exclude it.
  5. Check whether it actually worked

    get_uptime gives your agent current status, latency, uptime over 24 hours, 7 days and 30 days, and any open incident with its cause and how long it has been running. Worth asking immediately after a deploy, before you close the laptop.

Tools

Twelve tools, one API key

Feedback

list_feedback · get_feedback · update_feedback · resolve_feedback

Read the board with votes, categories and comments. Move a request through Planned and In progress. Resolve it with a public reply, and a changelog entry in the same call, which the reply then links to.

Changelog

list_changelog · publish_changelog · update_changelog

Write markdown release notes, tag them New, Improved or Fixed, publish or leave a draft. Published entries hit the public page, the RSS feed and every embedded widget at once.

Maintenance

list_maintenance · schedule_maintenance · transition_maintenance

Announce planned downtime in wall-clock time and a timezone, then start it now, complete it early or cancel it. During the window no incidents open and no false down-alerts go out.

Uptime

get_uptime · list_projects

Current status per monitor, latency, uptime over 24 hours, 7 days and 30 days, and open incidents with their cause. The full response captured from a failing check stays owner-only, in your dashboard and your alert email.

Trust

What an agent can reach, and what it can't

The MCP server has no database connection

It is a client of the same public REST API you could call with curl, authenticated with the same key. There is no privileged path: an agent can never do more through MCP than you could do with the key in your hand. Give it a read-only key and it can answer questions but change nothing. That holds for the hosted endpoint too. It keeps no session and stores no key, it just carries the one on the request through to the same API.
  • Read-only or read-write per key, so “summarise my feedback” and “publish this” don’t need the same level of trust.
  • Keys are hashed. The plaintext is shown once at creation and never again; revoke any key from the dashboard and it stops working immediately.
  • Nothing publishes silently. The tools that write are described to the model as public and irreversible, so it asks you before putting words on your changelog.
  • Scoped to your account. A key reaches your projects and no one else’s.

Stop context-switching to write a changelog

Free forever for one project, with the full API and MCP server included: no trial, no card. See the docs for the exact tool schemas.