Skip to main content
Glama
SistemaIntegra

I-Bot MCP

Official

ibot_list_chats

Lists and filters WhatsApp chats from the I-Bot panel, supporting device, status, tag, unread, and other filters. Returns chat details with pagination control and ceiling alerts.

Instructions

Lista e filtra chats do painel I-Bot. Usa a API interna do painel (sem navegador, ~1s; 250 chats em 1,8s) e cai no Playwright se ela falhar. Filtra por APARELHO (padrão: IBOT_DEVICE; vazio = todos), status, não lidas, arquivados, favoritos, tag, nome e número. Retorna nome, status, tags, aparelho, última mensagem, timestamp e não lidas. O retorno SEMPRE diz qual corte ocorreu (fim real da lista / teto do painel / limite pedido) — nunca corta em silêncio. TETO: a API interna PAGINA (medido 17/08/2026: 250 chats distintos numa consulta), mas o Playwright de fallback trava em 100 POR CONSULTA sem paginação (medido 14/08/2026: nenhum limit/offset traz o chat 101) — se o retorno avisar teto do painel, varrer além exige FATIAR por filtro e cruzar wa_chat_id. FORÇA DOS EIXOS, medida em produção: device é o mais forte (cada aparelho é uma janela própria; único jeito de isolar o inbound de UM número) > department (que é TAG, uma janela por tag) > status × order_by, que satura rápido — cruzar 6 status × 8 ordenações bate o teto em quase toda fatia e deixa um MIOLO inalcançável. Três armadilhas medidas: (1) whatsapp_number dá FALSO NEGATIVO — o chat existe, wa_chat_id igual ao buscado, e a busca volta vazia; a causa é o filtro de arquivados ser EXCLUSIVO (numa conta madura quase todo o histórico está arquivado), e leads já foram dados como 'sem chat' tendo chat ABERTO. Pela API interna isso está resolvido (busca por número que não acha nada refaz o pass entre arquivados e avisa), mas no fallback Playwright a armadilha continua: nunca conclua 'não tem chat' sem repetir com archived=true; (2) a ordenação padrão é por última mensagem, que AFUNDA o chat sem resposta (a última mensagem é a do cliente, antiga) — para caçar conversa parada sem dono use '-created', e para achar quem nem isso alcança use 'updated' (ascendente), que foi o que revelou leads invisíveis a 4 ciclos de varredura; (3) o nome do contato aqui é o do WhatsApp, não o do CRM ('.', '', nome de empresa) — buscar pelo nome que está no CRM dá falso negativo. SEMPRE rode um controle positivo (um chat de estado já conhecido) na mesma virada: sem ele não há como distinguir 'não existe' de 'a fatia não alcança'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoFiltrar por nome do contato (busca parcial).
limitNoMáximo de chats a retornar (padrão: 50, máximo: 1000). Acima de 100 o scroll precisa carregar mais lotes: conte ~2s a cada 100.
deviceNoFiltrar pelo APARELHO (número de origem) que recebe o chat. Padrão: IBOT_DEVICE; vazio ('') lista de TODOS os aparelhos. Aceita trecho do rótulo (ex.: 'comercial', os últimos dígitos do número) ou o id bruto do aparelho. É o corte mais forte que o painel oferece — o mesmo número pode existir em dois aparelhos com conversas DIFERENTES, e no Playwright cada aparelho é uma janela própria de 100. Não casou = ERRO explícito com a lista real de aparelhos, nunca lista sem filtro se passando por lista filtrada.
offsetNoQuantos chats descartar do início da lista (padrão: 0). Use com limit para paginar uma varredura grande sem reprocessar o mesmo trecho.
statusNoFiltrar por status do chat.
archivedNoSe true, retorna SÓ os arquivados (o filtro do I-Bot é exclusivo, não soma com os ativos).
order_byNoOrdenação. Padrão: -updated (mais recentes). Use -new_messages para ordenar por não lidas.
favoritedNoSe true, mostra apenas chats favoritados.
departmentNoATENÇÃO — este filtro é de TAG, não de departamento (os labels de checkbox do painel são todos tags, ex.: 'Lead Quente', 'Cliente | Plano Gold'). O nome do parâmetro é herança e engana; para filtrar por departamento de verdade use `responsavel`. Vale como eixo de fatiamento: cada tag é uma janela própria de 100. Não casou = ERRO explícito com as tags disponíveis.
responsavelNoFiltrar por QUEM está com o chat — é o dropdown 'Usuário/Departamento' do painel. Aceita vários de uma vez (regra OU: devolve chat de qualquer um da lista), misturando PESSOA e DEPARTAMENTO livremente, porque no painel os dois vivem no mesmo seletor. Ex: ["Maria Souza", "Financeiro"]. Aceita nome completo, parte do nome, e-mail ou o id. Use ["sem responsável"] para os chats que NINGUÉM pegou — é o eixo pra caçar conversa órfã, e combina bem com order_by='-created'. Nome que não existe ou que casa com mais de um = ERRO explícito com a lista real, nunca lista sem filtro se passando por filtrada. NÃO funciona no fallback Playwright: se a API do painel estiver fora, a tool devolve erro em vez de lista sem esse filtro.
unread_onlyNoSe true, mostra apenas chats com mensagens não lidas.
whatsapp_numberNoFiltrar por número WhatsApp (ex: 5511999990000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so exceptionally: it discloses the internal-API-first architecture with Playwright fallback, latency figures (~1s; 250 chats in ~1.8s), the measured pagination ceilings (250 via API, hard-stopped at 100 per query in the Playwright fallback), and the guarantee that truncation is always reported rather than silent. It also documents failure semantics (explicit error with the real device/tag list instead of an unfiltered list), a known false-negative mode for whatsapp_number, the exclusive (non-additive) archived filter, and that `responsavel` is unsupported in fallback mode.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, mechanism/cost, filters, return shape and the no-silent-truncation guarantee are correctly front-loaded ahead of the caveats, and every paragraph carries operational content. It is nonetheless a dense block with heavy capitalization and long parenthetical measurements; a tighter split between 'how to call' and 'how to run a sweep' would read better, though little is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, zero-required, no-output-schema tool with no annotations, the description supplies everything an agent needs: return field list, truncation reporting, fallback behavior, error semantics, per-axis semantics, and documented degradation cases. Nothing material for correct invocation is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description still adds meaning the schema cannot, notably the relative strength of the slicing axes, the trap that `department` is really a tag filter, the ordering pitfall where the default -updated buries unanswered chats, and the archived-filter false negative on whatsapp_number. It does not add syntax or format detail beyond the schema, which is why it sits at 4 rather than 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a precise verb+resource ('Lista e filtra chats do painel I-Bot') and immediately scopes the surface area (device, status, unread, archived, favorited, tag, name, number, plus the returned fields). An agent can tell this is the read/list entry point of the I-Bot panel without opening the schema, and it is clearly distinct from the sibling read tools (message status, chat links, custom fields, tags).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description goes far beyond 'when to use it': it ranks slicing axes by measured strength (device > department/tag > status×order_by), prescribes specific combinations for specific goals ('para caçar conversa parada sem dono use -created', 'sem responsável' for orphan chats), and warns when NOT to trust a result ('nunca conclua não tem chat sem repetir com archived=true'). It also mandates a positive control in the same run, which is explicit operational guidance rather than implied usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.