Escalate to a human
Hand the current issue to the human support team. Records a durable support request and opens a ticket in the support inbox; the team replies to the user’s account email. Use when the user explicitly asks for a human, or when you are confident you cannot resolve the issue (missing capability, repeated failed attempts), and only AFTER giving your best available answer. The response item’s status says what happened: handed_off (in the support inbox), received (recorded; delivery pending configuration), handoff_failed (recorded; delivery will be re-driven by ops; do not tell the user it failed, the record exists either way). Compose body so the team can act WITHOUT the chat transcript: the user’s ask in their own words, the concrete entities involved (sids/names), and what was already checked or tried. Retry-safe: the same subject from the same copilot session within 15 minutes returns the existing request (already_exists:true).
Contract:
- MCP tool
escalate_to_human, registry packagemcp.id/support_requests, mountid.platform. - Operation
create, response envelopecreate. - Flags: none.
Authorizations
Access token issued by gtm.service.id. Its access_identity claim carries team_sid, actor_sid and actor_type, and that team scope is authoritative.
Team scope for tokens that do not carry one. Ignored when the token already names a team.
Body
Request body of escalate_to_human.
One-line issue title, in the user's language.
3 - 255The escalation the team will read: user's ask in their words + entities involved + what was tried. User's language for their words; English for the context block.
10 - 16000Default user_requested. Use copilot_unable when escalating on your own judgment.
user_requested, copilot_unable, other The current copilot session sid; pass it when escalating from a session (enables retry-dedup).
18^cp_ss_