A maioria dos operadores que conecta o agente ao MCP da Cabgo termina a configuração inicial e nunca mais volta a verificar se as chamadas que o agente faz estão corretas. Não por falta de interesse, mas porque não têm um ritual de revisão estabelecido. O agente responde perguntas, gera relatórios, executa ações — e enquanto funciona, o operador presume que funciona bem. O problema é que um agente que «funciona» e um agente que funciona corretamente são duas coisas distintas: o primeiro responde, o segundo responde com as ferramentas certas, no tenant certo, sem retries desnecessários e sem padrões de chamada que indiquem que está aprendendo na marra convenções que deveria ter pré-carregadas a partir do skill.
O servidor MCP da Cabgo registra cada chamada do agente no histórico acessível por meio de `cabgo_my_mcp_usage` — ferramenta acionada, timestamp, tenantId resolvido, status do resultado e quantidade de retries. Esse histórico é a diferença entre presumir que o agente opera corretamente e poder verificá-lo. Este artigo documenta o que revisar nesse histórico toda semana, quais padrões indicam problemas antes de o operador percebê-los no output diário, e quais ações tomar quando um padrão se desvia do esperado. A revisão completa não leva mais de 10 minutos — mas transforma o agente de uma ferramenta que se usa com fé em uma que se usa com evidência.
O que o servidor MCP registra em cada chamada do agente
O histórico de uso do MCP não é um log de erros — é um registro de cada interação, bem-sucedida ou não. Cada entrada tem cinco campos que importam para a auditoria semanal: a ferramenta chamada (`tool_name`), o timestamp exato, o tenantId que o agente resolveu para aquela chamada (pode ser o default ou um especificado explicitamente no prompt), o status do resultado (`success`, `tier4_confirmation`, `rejected`, `timeout`) e o número de retries antes de a chamada se resolver. A maioria dos operadores nunca viu esse histórico porque o agente não o exibe por padrão — é preciso pedi-lo explicitamente com um prompt dirigido a `cabgo_my_mcp_usage`. O que aparece nessas entradas em 10 minutos revela mais sobre como o agente opera do que semanas de conversa normal.
O campo mais informativo para detectar problemas é `retry_count`. Um valor zero significa que o agente chamou a ferramenta uma vez e obteve o resultado esperado na primeira tentativa — o fluxo ideal. Um valor de um pode ser normal em conexões com latência variável. Dois ou mais retries na mesma chamada, em especial quando se trata de ferramentas destrutivas como atualizações de configuração ou mudanças de preço, indica quase sempre que o agente recebeu um cartão de confirmação Tier-4 e o interpretou como um erro transitório passível de nova tentativa — comportamento que acontece quando o skill não está carregado ou não está sendo ativado.
Cinco padrões de alerta que aparecem antes de o operador perceber o problema
Os problemas de configuração do agente não aparecem de repente — aparecem como padrões no histórico de chamadas antes de o operador perceber que algo está errado no output diário. Há cinco padrões que vale a pena procurar em cada revisão semanal:
- Chamadas frequentes a `cabgo_about` antes de outras ferramentas: o agente está fazendo descoberta do catálogo em cada sessão porque não tem o contexto pré-carregado do skill. Em operações onde o skill está corretamente instalado, `cabgo_about` deveria aparecer apenas na primeira sessão de um operador novo, não semana após semana.
- tenantId resolvido como 'default' em mais de 50% das chamadas quando a operação tem vários apps ativos: em um fluxo multi-tenant correto, as chamadas devem se distribuir entre tenants conforme o trabalho do operador. Uma concentração alta no default pode indicar que os prompts não estão especificando o tenant secundário quando a tarefa exige.
- Status `tier4_confirmation` seguido de `timeout` sem `success`: o agente recebeu o cartão de confirmação de uma ferramenta destrutiva e não completou o fluxo no TTL de cinco minutos. Indica que o operador fechou a conversa antes de confirmar, ou que o agente tentou a chamada de novo em vez de apresentar o cartão para aprovação.
- `cabgo_list_builds` aparecendo em contextos de status operacional diário: essa ferramenta devolve o histórico de deploys, não o status da operação em tempo real. Sua presença nesses contextos indica que o agente confundiu duas ferramentas de nomes parecidos mas propósitos distintos — confusão que o skill resolve com sua tabela de seleção.
- Chamadas em horários em que o operador não usa o agente: se o histórico mostra atividade às 2h da manhã ou em dias em que o operador não abriu o cliente, pode indicar uma integração externa usando o mesmo token, ou um script automatizado não documentado. Merece investigação antes de virar um problema de custos ou de segurança.
Como solicitar o histórico com um prompt que entrega output acionável
O histórico de `cabgo_my_mcp_usage` não é uma tela do dashboard — é uma ferramenta do servidor MCP que o agente chama quando o operador pede. O output padrão inclui as últimas 50 chamadas, o que em uma operação ativa cobre entre 3 e 5 dias. Para uma revisão semanal completa, o prompt deve especificar o período e o formato esperado; caso contrário, o agente produz uma narração livre difícil de comparar semana a semana. O prompt de auditoria deveria ser salvo na biblioteca de prompts do operador junto com os cinco prompts de trabalho diário — é o sexto que completa o ciclo operacional.
O que um histórico limpo confirma e o que um com ruído denuncia
Um histórico semanal limpo tem três características: a grande maioria das chamadas tem status `success` na primeira tentativa, as ferramentas chamadas correspondem ao tipo de tarefa que o operador costuma realizar (relatórios com ferramentas de leitura, ações com ferramentas de escrita), e os tenantIds refletem o padrão de trabalho real. Quando os três indicadores estão alinhados, o agente opera dentro das convenções do skill — não há ajustes urgentes. Um histórico limpo não exige ação: apenas confirma que a configuração atual sustenta o trabalho da semana sem desgaste.
Um histórico com ruído — retries elevados, ferramentas de descoberta antes de cada ação, status `rejected` em chamadas que o operador acha que executou com sucesso — denuncia um de dois problemas: configuração do agente ou deriva do prompt. A configuração envolve o skill e o token; a deriva do prompt acontece quando o operador começa a modificar seus modelos salvos sem preservar a especificidade que os faz funcionar. O histórico distingue os dois casos porque os problemas de configuração produzem padrões sistemáticos — o mesmo erro em chamadas distintas — enquanto a deriva do prompt produz erros específicos, que aparecem apenas em certas ferramentas ou certos tenants. Saber qual é qual antes de agir evita consertar o que não está quebrado.
A revisão semanal: cinco perguntas que cobrem a operação em dez minutos
Uma revisão produtiva não exige ler cada entrada do histórico — exige fazer cinco perguntas concretas sobre o output de `cabgo_my_mcp_usage`. Se as respostas estão dentro da faixa esperada, a operação do agente está saudável. Se uma se desvia, ela aponta exatamente onde olhar sem precisar de uma auditoria exaustiva:
- A média de retries por chamada está abaixo de 0,5 esta semana? Uma média maior indica que o agente está tentando de novo em vez de completar fluxos na primeira tentativa — a causa mais comum é o cartão Tier-4 não reconhecido por falta de skill.
- As chamadas a ferramentas destrutivas têm status `success` ou `tier4_confirmation` — e não `rejected` ou `timeout`? Um `timeout` ou `rejected` nessas ferramentas significa que o fluxo de confirmação não se completou dentro do TTL de cinco minutos.
- A distribuição de tenantId nas chamadas reflete como o operador usa seus apps? Se ele tem táxi e delivery ativos e 90% ou mais das chamadas vão sempre ao mesmo tenant, os prompts secundários provavelmente não estão especificando o tenant certo quando a tarefa exige.
- Há alguma ferramenta com um volume de chamadas muito acima do esperado para a semana? Um pico em uma ferramenta específica pode indicar um loop do agente ou uma automação externa não documentada com acesso ao token.
- O volume total de chamadas da semana é consistente com a frequência real de uso do operador? Uma discrepância grande — mais do que o dobro do volume típico ou atividade em horários incomuns — merece investigação antes de virar um problema de custos.
Problemas de configuração vs bugs de plataforma: como distingui-los e o que fazer com cada um
Há uma distinção importante entre um padrão que indica um problema de configuração — que o operador pode resolver sozinho — e um que indica comportamento inesperado do servidor MCP, que exige suporte técnico. A regra prática: se o histórico mostra chamadas corretas por parte do agente seguidas de respostas inesperadas ou erros não documentados do servidor, é um problema de plataforma. Se o histórico mostra chamadas incorretas — ferramenta errada, tenantId faltando, retries diante do Tier-4 — é um problema de configuração do agente. Os problemas de configuração são mais frequentes e têm solução direta: skill não instalado (instalar), skill instalado mas não ativando (verificar se o diretório está correto e se o arquivo se chama exatamente SKILL.md), prompts que não especificam tenantId em operações multi-tenant (adicionar o campo), confusão sistemática entre ferramentas de leitura e escrita (revisar a tabela de seleção do skill).
Os bugs de plataforma — respostas com formato inesperado, ferramentas do catálogo que devolvem erros não documentados, tokens que expiram antes do TTL declarado, tenantIds válidos que o servidor não reconhece — são reportados como issues no repositório do skill ou diretamente à equipe da Cabgo. O trecho relevante do histórico de `cabgo_my_mcp_usage` é a evidência mais útil para esse report: mostra exatamente o que o agente chamou, quando, com qual tenantId e qual resposta recebeu. Um report sem esse trecho obriga a equipe a reproduzir o problema do zero; um com o trecho permite identificar a origem em minutos.
Na primeira semana em que revisei o histórico, vi que o agente tinha tentado o cartão de confirmação três vezes antes de eu fechar a conversa. Isso me disse que o skill não estava carregado corretamente — ele estava tratando o Tier-4 como um erro do servidor. Dez minutos de revisão me deram mais clareza do que duas semanas de prompts na tentativa e erro.
O agente conectado ao MCP da Cabgo não é invisível para quem sabe onde olhar. O histórico de `cabgo_my_mcp_usage` registra cada decisão de ferramenta, cada tenantId resolvido, cada retry, cada confirmação pendente. Isso transforma a revisão semanal de 10 minutos no único controle de qualidade que roda em um nível mais profundo do que os prompts: não só verifica que o agente respondeu, mas que respondeu da maneira certa, com as ferramentas certas, sem padrões que indiquem que estão se perdendo convenções-chave na execução diária.
O arco completo de uma operação bem configurada com agentes tem três camadas: conectar o MCP com o skill instalado, definir os prompts de trabalho diário, e auditar o histórico toda semana para confirmar que as três camadas seguem alinhadas. A maioria dos operadores tem as duas primeiras. A revisão semanal é a terceira camada — a que transforma o agente de uma ferramenta que se usa com fé em uma que se usa com evidência. Dez minutos na segunda-feira de manhã é o custo dessa diferença.
