A feedback board has three permission levels and this surface labels each tool with the one it requires — anonymous for reads, authenticated for posting and commenting, collaborator for tagging and status changes, admin for deletion. That makes the boundary knowable before a call rather than after the request is refused, which matters when an agent is working through a queue of posts and would otherwise stop midway with half the batch done. The status-change tool is the one worth planning around: on Fider, responding to a post is a public act with a status attached, so it is not the same class of operation as editing a tag.
A Fider client covering the three objects a feedback board is made of: posts, comments and tags, with 16 tools spanning read, write and moderation.
- Posts read without authentication and are created with it; editing and deleting need a collaborator or admin role, and each tool states which.
- respond_to_post changes a post's status, which on a Fider board is the act of answering the community rather than a metadata edit.
- Comments have the full lifecycle with ownership enforced — update and delete require that you wrote it, or that you are an admin.
- Tags can be created, edited and deleted by an admin, and assigned or unassigned to posts by a collaborator.
FIDER_BASE_URL and FIDER_API_KEY — the base URL because Fider is self-hosted, so there is no default instance to assume.
One command plus a key — uvx --from git+https://github.com/ringostat/fider-mcp.git mcp-fider, then supply credentials