For a Pixelbase support assistant — one connected as a person on the support rota — three tools cover the queue, and a fourth family lets it draft replies for the person to send.

The support inbox. Mail is read by mailbox, and a mailbox is read by the person it is assigned to. So list_emails sees support@pxb.app only once that address is assigned to the person the assistant acts as (Domains & email → the address → assign); until then it isn't in the list of mailboxes list_email_folders returns, and a search of it finds nothing. Every list answer names the mailboxes it searched, so an empty page says whether that is why. Pass mailbox to read one inbox, unread=true for what nobody has opened, direction=INBOUND for what customers sent; rows are summaries with a snippet, and get_email or get_email_thread read the body in words.

The Support channels. Every customer company has one, and the rota reads them all. list_support_conversations is the queue — status is whose turn it is, read off the last message, so status=awaiting-reply is what we owe an answer — and get_support_conversation returns the whole conversation with each message marked ours or theirs. These need internal:support:read, the rota's own scope: one of the few internal-tier permissions a Pixelbase staffer can grant to a connection, and the only way these two tools appear.

The dashboard. list_notifications with unread=true is what still needs handling; source.kind says whether it came from support, a thread, a task or an order, and source.link opens it. It needs notifications:read, granted on the consent screen like any other.

Replying. The assistant drafts, the person sends: create_email_draft writes the reply into their Drafts folder, and send_email_draft — marked as reaching outside the company — sends it from the support address. There is no tool that sends mail straight away. Answering in a Support channel stays a person's act in Threads.