resolve_support_conversation
Mark a support conversation resolved, clearing it from the creator's open queue.
Mark a conversation resolved. It leaves the open triage queue and stops competing for the creator's attention.
Not destructive. The thread and its full history are kept, and it reopens by itself the moment the member writes again. Resolve only what has actually been answered — a resolved thread stops showing in the creator's triage list.
Requires ability
The token behind the MCP session must hold it, or the call is refused with TOKEN_MISSING_ABILITY.
Runs the same action as
The REST endpoint and this tool share one action, so validation, permissions and events are identical.
Fires one event
Delivered to every endpoint subscribed to it once the change is made.
Annotations
A client that honours annotations asks a person before running it.
Arguments
conversation_id*stringUUID of the support conversation to resolve.
What it returns
{ "data": { "conversation_id": "9e042b6f-5d81-4c37-a920-7b3e18cf6d45", "status": "resolved", "resolved_at": "2026-08-20T10:12:00Z" }}How it fails
TOKEN_MISSING_ABILITYtoken lacks support-conversation:update.
No support conversation found with that id. — unknown id, or outside the token's project scope.
Caveats
- Resolving does not notify the member. Send a reply first if they should know the matter is closed.
- Resolving an already-resolved conversation succeeds and emits the event again. Harmless, but deduplicate if you are posting notifications downstream.
- The member's next message reopens the thread automatically and raises
support.conversation.reopened. A blocked member's message does not — their thread stays resolved.
How is this guide?
Last updated on