{"slug": "using-mcp-for-a-support-handoff", "title": "Using MCP for a support handoff", "summary": "A DobroDesk engineer outlined a proposed MCP-based workflow for handing off customer support conversations, in which an AI client uses tools like search_conversations, list_assignment_targets and assign_conversation to find an open order thread, read its messages and suggest a teammate to take over. The design requires human confirmation before assignment, uses idempotency keys to safely retry timed-out requests, and scopes the assistant to a single teammate's role and OAuth grant, with separate permissions for customer details and internal notes. Access can be cut off by revoking grants and blocking reconnect for that teammate and application.", "body_md": "Before I pick up a question about an order, I'd want to see what we've told the customer so far. I wouldn't want to ask the customer for something they've already sent. The message in front of me might be their second or third attempt to get an answer. I'd want the assistant to read back a little, too.\n\nI work on DobroDesk, where an AI client can use MCP (Model Context Protocol) to call support tools. With that client [connected to the workspace](https://dobrodesk.com/help/connect-mcp-client-and-revoke-access), I could ask: \"Find the open conversation about order 8142, read the messages and suggest someone to take over.\" I've made up the order for this example.\n\nThe latest message might say \"Any news?\" I'd need to go back further to understand that. The timeline can flag that older messages may exist outside the recent window it returns. It also flags text that's been shortened. I can get more of an individual message by ID.\n\nAn order number would help me find the right conversation. I'd look through the open ones in the Orders Inbox with `search_conversations`. Search only gives me metadata, so this isn't yet the assistant reading what the customer said. I'd have to allow message reading separately, even if I already had the ID of the message I wanted.\n\nI might have a colleague in mind, but I'd still check the choices returned by `list_assignment_targets`. Those are people who can receive this conversation in its current Inbox. I might need the next page before I found the person I had in mind, so I'd use the cursor from that result. I could compare their availability and capacity there. They don't tell me whether Lena has dealt with the order before. That's something I would have to establish myself.\n\nBefore any of this is written, I would check the conversation and who I'm giving it to. In this example that's Lena. In this proposed client flow, the assistant would have to wait for my confirmation before calling `assign_conversation`.\n\nI might lose the response after the assignment has been made. I'd keep the original request and its `idempotencyKey`. That's the request I'd send again. Getting a timeout wouldn't be a reason to make a new key and start another assignment. If the first request finished and left a saved result, I get that result back. Otherwise, I can't yet tell Lena that the handoff is done.\n\nI'd be connecting the assistant as one teammate, not as the whole company. The assistant can only do what that teammate's role and the OAuth grant allow. DobroDesk also lets the owner limit the member, the application and that member's use of the application. All of them have to allow the action. The teammate doesn't get a new Brand or Inbox just by connecting an assistant.\n\nI'd leave customer details and internal notes out of this job. I'd have to give it permission to read each of those separately. I don't have to allow either just to let the assistant read the messages in this conversation. Every time it calls a tool, DobroDesk checks what that teammate and the application are allowed to do.\n\nIf I revoke this teammate's access to the application, its current grants stop working. They could connect it again later, though, if the policies still allow that. To prevent that as well, I'd block reconnect for the same teammate and application. I don't have to block everybody else's connection to deal with this one.\n\nI wouldn't use the reconnect switch on its own to cut off access. A grant that already exists can still work. I'd revoke those grants as well, for this teammate and application. If I allow them to reconnect later, they'll need to give consent again. The policies still have to allow it then.\n\nAI helped with the writing and revisions here. This order and these colleagues are fictional, and this is a proposed workflow.", "url": "https://wpnews.pro/news/using-mcp-for-a-support-handoff", "canonical_source": "https://dev.to/dmytro_shevchenko_eecc3e2/using-mcp-for-a-support-handoff-4552", "published_at": "2026-10-24 10:38:11+00:00", "updated_at": "2026-10-24 10:43:14.226776+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools"], "entities": ["DobroDesk", "Model Context Protocol", "MCP", "Lena"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/using-mcp-for-a-support-handoff", "markdown": "https://wpnews.pro/news/using-mcp-for-a-support-handoff.md", "text": "https://wpnews.pro/news/using-mcp-for-a-support-handoff.txt", "jsonld": "https://wpnews.pro/news/using-mcp-for-a-support-handoff.jsonld"}}