The design choice worth knowing is that both the message count and the response shape are capped on purpose: ten recent messages per chat, trimmed to the useful fields. That is what makes it possible to pull a batch of conversations into a session and ask what customers are actually complaining about, rather than hitting the context limit on the third chat. It reads; it does not reply, so nothing here can send a message to a customer.
A reader over the Channel Talk Open API. Two calls: one lists user chats by state, the other takes those chat ids and returns their messages, requesting them in parallel rather than one at a time.
- User chats listed by the state they are in, so an open queue and a closed backlog are separate questions
- Messages for several chats at once from a single call, fetched in parallel by chat id
- The ten most recent messages per chat rather than the whole history
- Responses reduced before they are returned — the fields that matter are kept and the rest of the API payload is dropped, so a large result set stays workable in a conversation
Channel Talk API credentials — an access key and a secret key from an app you create in their developer console. They can be passed on the launch command as --access-key and --secret-key, or set as CHANNEL_TALK_X_ACCESS_KEY and CHANNEL_TALK_X_ACCESS_SECRET in the environment. Node.js 18 or newer; it runs as npx -y mcp-channel-io. This is an unofficial client and covers part of the Channel Talk Open API rather than all of it — reading chats and their messages, not replying to them. ISC.
One command plus a key — npx -y mcp-channel-io, then supply credentials