MCP Tools

All 37 tools the Feedjolt MCP server exposes, grouped by resource, each with its required scope - plus the behaviors that surprise people: board and status deletion guards, changelog drafts vs publishing, and comment edit rules.

Every tool requires a scope on the calling principal - read, write, or delete. That grant comes from the OAuth consent screen or from an API key. See Permissions for what each scope means and how to grant it.

Posts

Tool	Scope	Purpose
`list_posts`	`read`	List/filter posts by board, status, or tag, with pagination
`search_posts`	`read`	Search posts by title keyword
`get_post`	`read`	Full post detail: body, status, tags, and up to 200 comments
`create_post`	`write`	Create a post on a board, authored by this key
`update_post`	`write`	Update a post's title, body, or internal visibility
`change_post_status`	`write`	Move a post to a new status, with an optional internal note
`move_post`	`write`	Move a post to a different board
`add_tag_to_post`	`write`	Tag a post (must use an existing tag)
`remove_tag_from_post`	`write`	Remove a tag from a post
`assign_post_owner`	`write`	Assign (or clear) a post's admin owner
`set_post_featured`	`write`	Feature or unfeature a post in portal listings
`merge_posts`	`write`	Merge a duplicate into a canonical post
`unmerge_posts`	`write`	Reverse a merge, restoring the source post
`delete_post`	`delete`	Permanently delete a post, its votes, and its comments

Boards

Tool	Scope	Purpose
`list_boards`	`read`	List all boards with visibility and post count
`create_board`	`write`	Create a board
`update_board`	`write`	Update a board, including archiving it
`delete_board`	`delete`	Delete an empty board only - see below

Tool	Scope	Purpose
`list_tags`	`read`	List all tags with post counts
`create_tag`	`write`	Create a tag
`update_tag`	`write`	Rename or recolour a tag
`delete_tag`	`delete`	Delete a tag - posts keep existing, they just lose it

Statuses

Tool	Scope	Purpose
`list_statuses`	`read`	List all workspace statuses
`create_status`	`write`	Create a status
`update_status`	`write`	Update a status's name, colour, roadmap visibility, or order
`delete_status`	`delete`	Delete a status, reassigning its posts - see below

Comments

Tool	Scope	Purpose
`list_comments`	`read`	List comments on a post, with pagination
`post_comment`	`write`	Add a comment (public or internal)
`update_comment`	`write`	Edit, pin, or change visibility of a comment - see below
`delete_comment`	`delete`	Permanently delete a comment, any author, any post

Changelog

Tool	Scope	Purpose
`get_changelog`	`read`	Recent published changelog entries
`create_changelog_entry`	`write`	Create a changelog entry as a draft - see below
`update_changelog_entry`	`write`	Update a changelog entry's title, body, or linked posts
`publish_changelog_entry`	`write`	Publish a draft - see below
`delete_changelog_entry`	`delete`	Permanently delete an entry, published or draft

Roadmap

Tool	Scope	Purpose
`get_roadmap`	`read`	Roadmap columns grouped by roadmap-visible statuses

Ordering

Tool	Scope	Purpose
`reorder_items`	`write`	Set the display order of boards, tags, or statuses in one call

Behaviors worth knowing

`delete_board` refuses populated boards

delete_board only works on a board with zero posts, and there is no override argument. Deleting a board cascades to every post, vote, and comment on it - permanently, with no undo - so MCP will not do that under any circumstances, no matter how the request is phrased.

To retire a board without losing its content, call update_board with archived: true instead. The board disappears from active listings; every post stays intact.

`delete_status` requires a reassignment target

Posts reference their status with a database constraint that blocks dropping a status still in use, so delete_status takes a mandatory reassign_to_status_id. Every post on the doomed status is moved there first, and each move gets its own status-history entry - identical to a manual status change.

Two statuses can never be deleted this way: the workspace's default status, and the last remaining status. Make another status the default first, or create a second status, before deleting either.

`create_changelog_entry` always drafts

create_changelog_entry only ever creates a draft - it is never visible to customers. Publishing is a separate, deliberate call: publish_changelog_entry. Publishing emails every subscriber and fires the changelog's webhooks, so it reaches real customers the moment it runs. Check the entry's content with update_changelog_entry before you publish it, not after.

`update_comment` can only edit its own text

update_comment edits three independent things - body, is_pinned, is_internal - but they don't follow the same rule. Editing body only works on a comment this API key posted itself; the service rejects an attempt to rewrite someone else's words. Pinning and visibility have no such restriction - a key can pin or hide/unhide any comment in the workspace regardless of who wrote it. delete_comment is unrestricted too: it removes any comment, which is what makes it useful for spam cleanup.

Other things to know

create_post counts against the workspace's monthly post quota - the same limit the dashboard's "New post" button respects. It fails once the quota is hit.
get_post and list_comments return internal comments as well as public ones - MCP agents see everything an admin sees. Don't relay an is_internal: true comment back to an end customer.
merge_posts is reversible with unmerge_posts, but the restore is degraded: votes, comments, and tags stay on the target post. The restored post comes back with 0 votes.
move_post refuses to move a post onto an archived board, and refuses a "move" to the board the post is already on.
reorder_items silently drops any ID that doesn't belong to the workspace (typo, wrong workspace, already deleted) instead of erroring. Compare reordered to submitted in the response to see if anything was dropped.

What MCP still can't do

MCP tools operate on one workspace's feedback data - posts, boards, tags, statuses, comments, changelog, roadmap. They don't touch workspace settings, billing, team members and roles, or webhook/widget/branding configuration. Those stay in the dashboard.