MCP no painel SMM: conecte seu assistente de IA à sua conta

MCP, sigla de Model Context Protocol, é um protocolo aberto que permite a um assistente de IA conversar com um sistema externo através de ferramentas descritas de forma padronizada, e no Panel Follows isso significa que o Claude, o ChatGPT ou o seu próprio bot podem buscar serviços, calcular preços, abrir pedidos e acompanhar o status direto na sua conta, sem você abrir o painel. Não é um chat que "adivinha" o que existe no catálogo. É uma conexão real: o modelo enxerga uma lista de ferramentas, chama uma delas com parâmetros, recebe uma resposta em JSON e usa esse dado para responder você.

Este guia é operacional. Ele mostra o que existe hoje na sua conta, com os nomes exatos das telas em português, os endereços que você vai colar no seu cliente de IA, as permissões que você concede quando clica em "Autorizar conexão", o que acontece nos bastidores do OAuth, quais das 18 ferramentas gastam dinheiro de verdade e quais só leem, e o que o assistente simplesmente não consegue fazer, por mais que você peça.

Duas coisas precisam ficar ditas logo no começo, porque mudam a forma de ler o resto. A primeira: criar pedido gasta saldo real e não tem volta. O servidor obriga o modelo a passar por uma prévia de preço e a pedir sua confirmação antes de abrir qualquer coisa, mas quem aperta o botão do "sim" é você, então leia o valor antes de responder. A segunda: usar MCP não custa nada além do próprio pedido. Não existe assinatura, taxa de integração ou cobrança por chamada de ferramenta. O que sai do seu saldo é o preço do serviço que você comprou, exatamente como se tivesse clicado em "Fazer pedido" na tela.

Se você ainda não conhece a operação básica do painel (saldo, catálogo, status de pedido, reposição), vale ler antes o guia completo de como usar o Panel Follows. Este texto assume que você já sabe o que é um serviço, o que é uma quantidade mínima e o que é entrega parcial. A página de configuração fica em /pt-br/dashboard/mcp, no item de menu "Assistente de IA".

O que é MCP e para que ele serve em um painel SMM?

MCP é um padrão de comunicação entre modelos de linguagem e sistemas externos. A analogia mais usada é a de uma tomada padronizada: em vez de cada aplicativo de IA inventar seu jeito de falar com cada serviço, todo mundo fala o mesmo idioma. Um servidor MCP publica três coisas para o cliente: ferramentas (ações que o modelo pode executar), comandos prontos (fluxos de trabalho pré-escritos) e recursos (documentos que o modelo pode ler). O nosso servidor publica ferramentas e comandos prontos; a lista de recursos existe no protocolo, mas volta vazia.

O que muda na prática, num painel SMM? Antes, para saber quanto custa 5.000 seguidores em três serviços diferentes, você abria o catálogo, filtrava por plataforma, clicava em cada serviço, lia "Preço por 1.000", fazia a conta de cabeça e comparava. Com o assistente conectado, você escreve uma frase, e ele faz as três consultas, monta a tabela comparativa e mostra o valor calculado. A informação é a mesma, a fonte é a mesma, o que muda é o número de cliques e o tempo.

O ganho maior não está na consulta única, está na repetição. Quem administra várias contas, ou vende para clientes, faz o mesmo ciclo dezenas de vezes por semana: procurar o serviço adequado, checar mínimo e máximo, calcular o valor, abrir o pedido, conferir o status dois dias depois, pedir reposição no que caiu. Cada uma dessas etapas é uma ferramenta no servidor MCP. Encadeadas por um assistente, viram uma conversa em vez de uma sequência de telas.

Vale marcar o limite honesto desde já: o assistente não é um vendedor nem um estrategista. Ele lê o catálogo que existe, calcula com os preços que existem e abre o pedido que você aprovou. Ele não sabe se o seu perfil está público, não sabe se o serviço vai entregar bem hoje, e não tem opinião confiável sobre qual fornecedor é melhor. Essas decisões continuam suas, e a forma de tomá-las com dados está descrita no guia de uso do painel.

Uma última definição que evita confusão de vocabulário. Servidor MCP é o lado que oferece as ferramentas: no nosso caso, um endereço na internet mantido pelo painel. Cliente MCP é o aplicativo onde você conversa: Claude, Cursor, um editor com suporte a MCP, ou um programa que você mesmo escreveu. Você não instala nada nosso na sua máquina. Você adiciona um endereço no seu cliente e autoriza a conexão.

Por que existem dois servidores MCP no painel e qual deles é o seu?

O painel expõe dois servidores MCP diferentes, com públicos diferentes, e confundir os dois é a primeira fonte de erro de quem lê a documentação rápido demais. Um é para o cliente do painel, ou seja, você, que compra serviços. O outro é para o dono do painel, quem administra o negócio.

	Servidor do usuário	Servidor de administração
Endereço	POST /api/mcp/user	POST /api/mcp
Quem conecta	o cliente do painel	o dono do painel
Identificação	token OAuth 2.1 ou chave de API da conta	uma única chave secreta de servidor
Alcance	apenas a própria conta, 18 ferramentas	o painel inteiro, 57 ferramentas
Registro	log de auditoria com a conta preenchida	log de auditoria sem conta vinculada

Os dois rodam sobre o mesmo núcleo de transporte, então o comportamento de protocolo é idêntico: mesma negociação de versão, mesmo formato de erro, mesmo corte de resposta. O que muda é quem entra e o que se enxerga depois de entrar.

Se você é cliente, o seu é o primeiro: https://panelfollows.com/api/mcp/user. Ele é isolado por conta. Não existe parâmetro, truque de prompt ou pedido educado que faça uma ferramenta desse servidor devolver dados de outro usuário: a conta vem do token, não do texto da conversa. E não existe nele nenhuma ferramenta de administração, então nem em teoria o modelo pode mexer em preço, fornecedor ou catálogo.

Se você é dono de um painel filho, preste atenção neste detalhe: os dois papéis convivem. Como cliente do Panel Follows, você conecta seu assistente ao servidor do usuário para comprar. Como dono do seu próprio painel white label, os seus clientes conectam os assistentes deles ao endereço do seu domínio. Cobrimos essa parte adiante, na seção sobre revendedores.

Quais são as 18 ferramentas que o assistente enxerga?

O servidor do usuário publica 18 ferramentas, agrupadas em cinco áreas. Os nomes são fixos e em inglês, porque é assim que o modelo as chama; você não precisa decorar nenhum deles, mas conhecer a lista ajuda a entender o que é possível pedir.

Área	Ferramentas
Conta	get_account
Catálogo	list_platforms, list_categories, search_services, get_service
Pedidos	preview_order, create_order, create_orders_bulk, list_orders, get_order, cancel_order, refill_order
Reposição	list_refills, get_refill
Automação	list_events, list_webhooks, create_webhook, delete_webhook

Doze dessas ferramentas são de leitura pura: get_account, list_platforms, list_categories, search_services, get_service, preview_order, list_orders, get_order, list_refills, get_refill, list_events e list_webhooks. Elas não alteram nada e não gastam saldo. As outras seis escrevem: create_order, create_orders_bulk, cancel_order, refill_order, create_webhook e delete_webhook.

Vale um detalhe técnico que tem efeito prático. Cada ferramenta chega ao cliente acompanhada de duas dicas padronizadas: se ela é somente leitura e se ela é destrutiva. Entre as que escrevem, quatro são marcadas como destrutivas (create_order, create_orders_bulk, cancel_order e delete_webhook) e duas não são (refill_order e create_webhook), porque pedir reposição e cadastrar um endereço de webhook não desfazem nada nem gastam dinheiro. Clientes de IA que respeitam essas dicas costumam pedir uma confirmação extra nas destrutivas.

O que cada área entrega, em linguagem direta:

• Conta. get_account devolve o identificador da conta, o e-mail, o saldo disponível em USD e o limite de requisições. É a ferramenta que responde "quanto eu tenho?" antes de qualquer compra.
• Catálogo. list_platforms e list_categories dão a árvore de navegação. search_services é o buscador de verdade, com filtros por texto, plataforma, categoria, tipo, suporte a reposição, suporte a cancelamento, entrega gradual e faixa de preço mínimo e máximo; a página traz 20 resultados por padrão e no máximo 50. get_service abre a ficha completa de um serviço.
• Pedidos. preview_order calcula sem comprar. create_order compra. create_orders_bulk compra em lote. list_orders e get_order acompanham. cancel_order e refill_order tratam do pós-venda.
• Reposição. list_refills e get_refill mostram as solicitações de reposição e em que pé elas estão.
• Automação. list_events lê o fluxo de eventos da conta, e o trio de webhooks permite ao assistente cadastrar, listar e remover endereços que recebem notificações.

Um ponto que economiza muita dor de cabeça: os nomes dos parâmetros das ferramentas são exatamente os mesmos da API v3. service, link, quantity, runs, interval, comments, username, posts, min, max, usernames, hashtag, hashtags, answer_number, groups, keywords, media. Quem já integrou a API não precisa aprender um segundo vocabulário, e quem começa pelo MCP já sai sabendo integrar. A referência completa fica na documentação da API.

Onde o assistente lê o que ele não pode adivinhar: get_service

Essa ferramenta merece um parágrafo próprio porque é ela que separa uma conversa útil de um chute caro. Ao chamar get_service com o número de um serviço, o modelo recebe o preço, a quantidade mínima e máxima, se há reposição, se há cancelamento, se há entrega gradual, o tempo médio de conclusão e, o mais importante, a lista de campos que aquele pedido exige (fields).

Por que isso importa? Porque o formulário de pedido não é sempre o mesmo. Um serviço padrão pede link e quantidade. Um de comentários personalizados pede uma lista de comentários e nem aceita quantidade. Um de enquete pede o número da opção. Um de menções por hashtag pede a hashtag. Se o modelo tivesse que adivinhar, ele erraria, e o erro só apareceria no momento da compra.

Com a lista de campos vindo do servidor, o comportamento correto é o assistente perguntar a você o que falta antes de tentar comprar. Se ele pedir "qual é o link da mídia de onde saem as curtidas?", não é invenção dele: é um campo obrigatório daquele serviço específico. Responda e siga.

O mesmo vale para os limites. Quantidade fora da faixa devolve um erro de código fixo, e o modelo é instruído a repassar a mensagem como ela veio, sem inventar solução. Se o assistente disser que a quantidade está fora da faixa permitida, o número certo está na ficha que ele acabou de ler.

Como conectar seu assistente de IA ao painel em três passos

A página "Assistente de IA", no menu do painel, existe justamente para isso, e o miolo dela cabe em três frases. O cartão do topo se chama "Endereço de conexão" e traz o endereço com um botão "Copiar".

1. Copie o endereço e adicione ao seu cliente de IA como servidor MCP. O endereço é https://panelfollows.com/api/mcp/user. Se você é cliente de um painel filho, o endereço é o mesmo caminho no domínio daquele painel.
2. O cliente traz você até aqui e você autoriza a conexão. O navegador abre a tela de autorização do painel. Se você não estiver logado, o painel manda você para o login primeiro e devolve você para a mesma tela depois. Se preferir, marque a caixa de acesso somente leitura.
3. Depois é só conversar. "Mostre os preços de seguidores no Instagram" ou "como estão meus últimos pedidos" já funcionam.

O texto de apoio na tela é explícito sobre a parte que mais gera receio: "A autorização acontece aqui no painel; sua senha nunca é compartilhada com o cliente." Isso não é retórica de marketing, é a descrição literal do fluxo. Você digita a senha na página do Panel Follows, dentro do seu navegador, e o cliente de IA recebe de volta apenas um token de acesso com validade curta. O cliente nunca vê a senha, nunca vê o seu e-mail antes de você autorizar, e não consegue trocar o token por credencial de login.

Um detalhe operacional: a conexão é feita uma vez por cliente. Se você usa dois aplicativos de IA diferentes, cada um faz o próprio fluxo e aparece como uma linha separada em "Assistentes conectados". Isso é intencional: dá para revogar um sem derrubar o outro.

Configuração por cliente: linha de comando, arquivo JSON e chave de API

A própria página do painel traz um cartão chamado "Configuração por cliente" com os exemplos prontos. A observação embaixo dele resume a compatibilidade: funciona com qualquer cliente MCP que suporte OAuth 2.1, e clientes que enviam cabeçalhos também podem usar uma chave de API.

Cliente de linha de comando. Um comando resolve, e o fluxo de autorização abre no navegador na primeira vez que você usar uma ferramenta:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user

Cliente com arquivo de configuração. Vários aplicativos leem um JSON com a lista de servidores. O bloco mínimo é este:

{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }

Cliente que envia cabeçalho, com chave de API. Se o seu ambiente não abre navegador (um servidor sem interface gráfica, um script de automação, um contêiner), pule o OAuth e mande a chave direto:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
  --header "Authorization: Bearer pf_live_..."

Teste cru, sem cliente nenhum. Para verificar se a chave funciona antes de configurar qualquer aplicativo, uma chamada de curl já lista as ferramentas:

curl -s https://panelfollows.com/api/mcp/user \
  -H "Authorization: Bearer pf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Se essa chamada devolver uma lista de ferramentas em JSON, está tudo certo do lado do servidor, e qualquer problema restante é configuração do cliente. Se devolver 401, a chave está errada ou foi revogada. As chaves ficam em /pt-br/dashboard/api, e o cartão do MCP tem inclusive um atalho para lá com o rótulo "Chaves de API".

Uma observação sobre o transporte, para quem for depurar: o servidor é HTTP puro, sem sessão e sem fluxo SSE. Abrir o endereço no navegador com um GET devolve HTTP 405 e uma mensagem dizendo que SSE não é suportado e que se deve usar POST para JSON-RPC. Isso é comportamento esperado, não falha. Todo o protocolo acontece em requisições POST independentes, o que tem uma consequência boa: nenhum estado de sessão fica pendurado, e uma conexão interrompida não deixa lixo do lado do servidor.

O que o fluxo OAuth 2.1 faz nos bastidores?

Se você só quer usar, os três passos da seção anterior bastam. Se você quer entender (ou precisa explicar para um cliente ou para um time de segurança), o fluxo completo tem seis etapas, e todas seguem padrões públicos.

1. Descoberta pelo erro. O cliente faz a primeira chamada sem credencial e recebe 401. Junto vem um cabeçalho WWW-Authenticate que aponta o endereço dos metadados do recurso protegido. Esse é o mecanismo do RFC 9728, e ele existe para que o cliente não precise de configuração manual: o próprio erro ensina o caminho.
2. Leitura dos metadados. O cliente busca /.well-known/oauth-protected-resource, que aponta para /.well-known/oauth-authorization-server (RFC 8414). Aí estão descritos os endereços de autorização, de token e de registro, além do que o servidor aceita.
3. Registro dinâmico. O cliente se cadastra sozinho com um POST /api/mcp/oauth/register (RFC 7591) e recebe um identificador de cliente. É um cliente público, ou seja, sem senha própria: a autenticação é feita por PKCE. O registro é limitado a 10 tentativas por hora por endereço IP, o que impede alguém de encher a base de cadastros automáticos.
4. Autorização no navegador. O cliente abre GET /api/mcp/oauth/authorize, que leva você para a tela de autorização do painel, no caminho /mcp/connect. Sem sessão ativa, você passa pelo login e volta para a mesma tela.
5. Sua decisão. Você lê o que está sendo pedido, marca ou não a caixa de somente leitura, e clica em "Autorizar conexão" ou em "Recusar".
6. Troca do código pelo token. O cliente chama POST /api/mcp/oauth/token e converte o código de autorização em um token de acesso. PKCE com S256 é obrigatório: o método plain é recusado, como manda o OAuth 2.1.

Os metadados de descoberta declaram exatamente o seguinte, e vale conferir se você está integrando um cliente próprio:

Campo do documento de descoberta	Valor
response_types_supported	["code"]
grant_types_supported	["authorization_code", "refresh_token"]
token_endpoint_auth_methods_supported	["none"]
code_challenge_methods_supported	["S256"]
authorization_response_iss_parameter_supported	true (RFC 9207)
resource_indicators_supported	true (RFC 8707)

Três regras adicionais que decidem se a sua conexão vai dar certo:

• Endereços de retorno. São aceitos endereços https, endereços locais em http (127.0.0.1 e localhost) e esquemas próprios de aplicativos, como cursor:// ou vscode://. Endereço remoto em http simples é recusado.
• Correspondência exata. O endereço de retorno enviado na autorização precisa bater com o que foi registrado. A única flexibilidade é a porta do endereço local, porque clientes de desktop escolhem porta livre a cada execução (RFC 8252).
• O verificador PKCE precisa ter entre 43 e 128 caracteres. Cliente que gera valor menor recebe erro no endereço de token.

E um detalhe elegante que interessa a revendedores: todos esses endereços são gerados a partir da origem da requisição. Quando um cliente de painel filho conecta pelo domínio dele, o emissor declarado é aquele domínio, e o endereço do painel principal não aparece em lugar nenhum do fluxo. A marca branca continua branca até dentro do OAuth.

Quando conectar com chave de API faz mais sentido?

OAuth é o caminho padrão porque não exige que você copie e cole segredo nenhum, e porque ele permite revogar um cliente específico sem tocar nos outros. Mas nem todo ambiente tem navegador, e nem toda automação é interativa. Para esses casos, o servidor aceita autenticação por cabeçalho.

Os valores aceitos como credencial são três: um token OAuth (com o prefixo pf_mcp_), uma chave da API v3 (com o prefixo pf_live_) e a chave hexadecimal de 64 caracteres da API de revendedor mais antiga. O cabeçalho pode ser Authorization: Bearer ou X-Api-Key. Qual caminho está em uso é reconhecido apenas pelo prefixo do valor, o que torna a implementação simples e previsível.

Critério	Conexão por OAuth	Conexão por chave de API
Precisa de navegador	Sim, uma vez	Não
Você copia algum segredo	Não	Sim, a chave
Permissão restrita a leitura	Sim, opcional	Não, sempre acesso total
Aparece em "Assistentes conectados"	Sim, com botão "Desconectar"	Não, a chave é gerenciada na página de API
Expira sozinho	Sim, token de 8 horas renovável	Não, vale até você revogar
Melhor para	uso pessoal em um aplicativo de IA	servidor, script, contêiner, automação sem tela

A regra prática: se tem navegador, use OAuth; se não tem, use chave. E entenda a consequência da escolha: uma conexão feita com chave é sempre de acesso total. A restrição de permissão só existe no OAuth, porque é lá que existe uma tela onde você marca a caixa. Uma chave é uma credencial da conta inteira, e quem a possui pode fazer o que a conta faz.

Por isso, chave merece o mesmo cuidado de senha. Não coloque em repositório público, não mande por chat, e se desconfiar de vazamento, gere outra: a antiga para de funcionar na hora. Se você já usa a API para integrar seu sistema, a documentação para desenvolvedores explica o formato das chaves e o rodízio delas em detalhe.

O que você vê na tela de autorização e o que está autorizando?

A tela de autorização fica no endereço /mcp/connect e só faz sentido dentro de um fluxo iniciado pelo seu cliente de IA. Ela não é uma página que você visita por conta própria, não é indexada por buscadores, e abrir o endereço direto sem um pedido de conexão válido devolve a mensagem "Este pedido de conexão é inválido ou expirou. Recomece pelo seu cliente.".

O que aparece na tela, item por item:

Elemento	O que ele mostra
Título	"{nome do cliente} quer se conectar à sua conta"
Texto de apoio	"Se você autorizar, este aplicativo poderá fazer o seguinte em seu nome."
"Conta"	o e-mail da conta que está logada agora
"Vai redirecionar para"	o endereço de retorno para onde o cliente será enviado
Lista de permissões	o que a conexão vai poder fazer
Caixa de seleção	"Conceder acesso somente leitura (sem criar pedidos)"
Botões	"Autorizar conexão" e "Recusar"

Preste atenção em dois campos antes de clicar. O primeiro é o nome do cliente: ele vem do cadastro que o aplicativo fez, e se você não reconhece o nome, não autorize. O segundo é o endereço de retorno: é para lá que o código de autorização vai. Se você iniciou a conexão em um aplicativo no seu computador, esse endereço deve ser local (algo em 127.0.0.1 ou localhost) ou o esquema próprio do aplicativo. Um endereço estranho de um site que você nunca viu é motivo suficiente para clicar em "Recusar".

Vale explicar por que esse cuidado importa. O fluxo é resistente por construção: o código de autorização vale 10 minutos e uma única vez, o endereço de retorno precisa bater com o que foi registrado e a troca do código exige o verificador PKCE que só o cliente legítimo tem. Mesmo assim, a tela de autorização é o ponto onde uma pessoa decide, e nenhuma proteção técnica substitui a leitura de dois campos antes de aprovar.

Depois de autorizar, você volta automaticamente para o cliente e ele já pode chamar as ferramentas. O painel registra a conexão e ela passa a aparecer na lista "Assistentes conectados", com a data em que foi criada.

O que a permissão "Somente leitura" desliga de verdade?

Existem dois escopos de permissão no servidor: leitura da conta e escrita na conta. Quando o cliente não pede nada específico, os dois são concedidos. Quando você marca a caixa "Conceder acesso somente leitura (sem criar pedidos)" na tela de autorização, o token sai apenas com o escopo de leitura.

E aqui está a decisão de projeto que faz diferença: o servidor não se limita a proibir as ferramentas de escrita, ele simplesmente não as mostra. A lista de ferramentas devolvida para uma conexão somente leitura tem 12 itens em vez de 18. As seis que escrevem não existem naquela sessão. O modelo não pode chamar o que ele não enxerga.

Por que não bastaria instruir o modelo a não usar? Porque instrução é texto, e texto é sugestão. Um modelo pode se confundir, um prompt mal formulado pode empurrar em outra direção, e o resultado de "quase sempre obedece" em uma ferramenta que gasta dinheiro é inaceitável. Filtrar a lista é a única forma que não depende do comportamento do modelo. Além disso, o servidor acrescenta uma nota na instrução dizendo que aquela conexão é somente leitura e que, para comprar, o usuário precisa remover a restrição no painel e conectar de novo.

Você quer que o assistente	Escolha na tela
Consulte preços, compare serviços e leia status	"Somente leitura" resolve
Faça pedidos, cancele ou peça reposição	Deixe a caixa desmarcada, acesso total
Cadastre webhooks e automatize notificações	Deixe a caixa desmarcada, acesso total
Só monitore uma conta que outra pessoa opera	"Somente leitura" é a escolha certa

Um caso de uso comum vale ser dito com todas as letras: se você quer que um assistente monte relatórios ou responda perguntas sobre a operação sem nenhum risco de compra acidental, somente leitura é a configuração correta e ela é definitiva, não uma preferência que o modelo pode contornar.

Uma nota técnica para quem escreve cliente próprio: escopos que o servidor não reconhece (por exemplo openid, profile, email) são simplesmente ignorados, sem erro. O cliente pede, o servidor descarta o que não existe e concede o que existe. Isso evita que um cliente genérico de OAuth quebre na primeira tentativa.

A permissão fica visível depois. Na lista "Assistentes conectados", cada linha traz um selo: "Acesso total" ou "Somente leitura". Se você não lembra o que autorizou há três semanas, é ali que a resposta está.

Em que ordem o assistente cria um pedido?

O servidor não deixa esse fluxo por conta do modelo. Ele entrega, junto com as ferramentas, uma instrução que descreve a ordem obrigatória, e essa ordem existe por um motivo simples: criar pedido gasta dinheiro real e não tem desfazer.

1. Buscar o serviço. O modelo chama search_services com o que você pediu (plataforma, categoria, texto de busca) e anota o número do serviço.
2. Ler a ficha. Com get_service, ele lê mínimo e máximo, suporte a reposição, suporte a cancelamento, tempo médio e a lista de campos obrigatórios.
3. Calcular o valor. Com preview_order, ele obtém o valor exato sem abrir nada. A resposta traz o valor da cobrança, o saldo que sobraria depois e um indicador de saldo suficiente.
4. Pedir sua confirmação explícita. A instrução é clara: sem aprovação, não se chama create_order.
5. Abrir o pedido. Com create_order, e depois informar o número do pedido.

Na prática, a conversa se parece com isto. Você escreve algo como "quero mil curtidas neste post", cola o link, e o assistente responde com uma comparação de serviços, dizendo preço, faixa de quantidade, se tem reposição e tempo médio de cada um. Você escolhe. Ele então calcula e diz o valor exato da cobrança e quanto sobraria de saldo, e pergunta se pode seguir. Você responde que sim. Ele abre e devolve o número do pedido.

Repare no papel de preview_order. Ela é a peça que transforma uma conversa em algo auditável: o valor que você aprova é o valor calculado pelo servidor, não uma conta feita pelo modelo em cima de um preço lido de um texto. Modelos erram aritmética, principalmente com casas decimais. O servidor não erra, porque é o mesmo cálculo que roda quando você clica em "Fazer pedido" na tela.

Outro cuidado embutido: os valores voltam como texto decimal, não como número de ponto flutuante, e a instrução manda o modelo repassar como veio, sem arredondar. Isso evita a classe de erro em que um valor de quatro casas decimais vira dois centavos a mais ou a menos na hora de contar para você.

E se o saldo não der? O indicador de saldo suficiente volta negativo, o assistente avisa antes de tentar, e você resolve pelo painel. Adicionar saldo não é uma ferramenta do servidor, o que nos leva ao próximo ponto importante.

O erro de leitura de preço mais caro: per_1000 contra per_order

Esse é o detalhe que mais custa dinheiro em qualquer integração com painel SMM, e ele existe no MCP exatamente como existe na tela. Na resposta de preço, existe um campo de unidade. Quando ele vale per_1000, o preço é para mil unidades. Quando vale per_order, o preço é do pedido inteiro, do pacote fechado.

Ignorar essa distinção erra o valor em mil vezes, para mais ou para menos. Um pacote que custa vinte e poucos dólares, lido como se fosse preço por mil, vira uma fração de centavo na conta de quem não olhou a unidade. Do outro lado, um serviço comum lido como pacote parece absurdamente caro.

Unidade do preço	Como calcular	Quando aparece
per_1000	preço dividido por mil, multiplicado pela quantidade	a maioria dos serviços do catálogo
per_order	o preço já é o total	pacotes e serviços cuja quantidade máxima é 1

A instrução do servidor avisa o modelo sobre isso em texto explícito, e a ferramenta preview_order existe justamente para tornar a discussão irrelevante: se você sempre passar pela prévia, o valor vem pronto do servidor e a unidade deixa de ser um problema seu. O risco só aparece quando alguém tenta pular a prévia e calcular de cabeça, ou quando um relatório é montado a partir do campo de preço bruto sem olhar a unidade.

Se você está escrevendo seu próprio cliente ou montando planilhas de custo com os dados que o assistente extrai, guarde a regra: nunca compare preços de serviços sem antes normalizar pela unidade. Dois serviços com o mesmo número no campo de preço podem ter custos que diferem em três ordens de grandeza. A mesma armadilha, do lado da tela, está explicada no guia de uso do painel, onde ela aparece com o rótulo "Preço por 1.000".

Como funcionam pedido em lote, entrega gradual e tipos especiais?

O assistente não fica preso ao pedido simples. Três recursos do painel aparecem nas ferramentas, cada um com regra própria.

Pedido em lote. A ferramenta create_orders_bulk aceita até 50 pedidos em uma única chamada. Os itens são processados em ordem, e o comportamento em caso de erro é o que você quer numa operação real: se um item falhar, os outros continuam. Cada item devolve o próprio resultado, então você recebe uma lista dizendo quais entraram, com que número, e quais falharam, com qual motivo. Não existe o cenário de perder o lote inteiro por causa de uma linha com link malformado.

Entrega gradual. Os parâmetros são runs (o número de lotes) e interval (o intervalo em minutos). Aqui vale repetir o alerta que já derrubou muita gente na tela do painel: com entrega gradual ativa, a quantidade informada é por lote, não o total. Quantidade 500 com 6 lotes entrega 3.000 unidades e cobra por 3.000. A prévia mostra o valor real antes de qualquer coisa, então use a prévia e leia o número. O funcionamento e as expectativas realistas desse recurso estão detalhados no artigo sobre entrega gradual e serviços automáticos no Instagram.

Tipos especiais. Comentários personalizados, enquete, menções em suas várias formas, convites para grupos, palavras-chave de SEO, curtidas em comentário: cada tipo pede campos próprios, e todos usam os mesmos nomes da API v3. A regra que vale para todos: o campo obrigatório vem da ficha do serviço, e o assistente deve ler a ficha antes de montar o pedido.

Tipo de serviço	O que o assistente precisa perguntar	De onde vem a quantidade
Padrão	link e quantidade	do que você informa
Comentários personalizados	a lista de comentários	do número de linhas, sem campo de quantidade
Enquete	link, quantidade e o número da opção	do que você informa
Menções por hashtag	link, quantidade e a hashtag	do que você informa
Menções por lista própria	link e a lista de usuários	do número de linhas
Convites para grupos	link, quantidade e a lista de grupos	do que você informa
Assinatura (automático)	usuário, mínimo e máximo por post, número de posts	do máximo por post multiplicado pelos posts

Uma consequência prática dessa tabela: nos tipos em que a quantidade sai das linhas, não adianta o modelo enviar um campo de quantidade. Se você ditar dezessete comentários, o pedido é de dezessete, e o preço acompanha. A instrução do servidor diz isso explicitamente ao modelo, então um assistente bem comportado vai pedir os comentários e contar as linhas em vez de perguntar "quantos?".

O que o assistente não consegue fazer?

Essa é a seção mais importante do artigo para quem se preocupa com risco, e a resposta é curta: bem menos do que a imaginação sugere. O cartão "O que o assistente pode fazer", na página do painel, resume em três linhas, sendo a terceira a que interessa aqui: "Não pode adicionar saldo, sacar dinheiro, ver sua senha nem acessar outras contas."

Detalhando os limites:

• Não adiciona saldo. Não existe ferramenta de pagamento. O assistente pode dizer que o saldo não é suficiente, e só. Recarregar continua sendo uma ação sua, no painel, pelas formas de pagamento ativas.
• Não saca dinheiro. Não existe ferramenta de saque nem de transferência entre contas.
• Não vê sua senha. A senha nunca sai do painel. No fluxo OAuth, você a digita na página do Panel Follows e o cliente recebe um token. Na conexão por chave, nem senha existe no caminho.
• Não acessa outras contas. A conta é determinada pelo token, não pelo texto da conversa. Não há parâmetro de "usuário" em nenhuma ferramenta.
• Não muda preço. Preço, margem, fornecedor e catálogo são domínio da administração, e nada disso existe no servidor do usuário.
• Não abre chamado de suporte. Se você precisar de atendimento humano, o caminho é a página de suporte do painel. O assistente pode até ajudar a redigir o texto, mas quem envia é você.
• Não altera dados de cadastro. Nome, e-mail, senha e verificação em duas etapas ficam fora do alcance das ferramentas.

Um limite mais sutil, e que vale entender: o assistente não sabe o que acontece fora do painel. Ele não verifica se o seu perfil está público, não percebe se você trocou o nome de usuário no meio da entrega e não tem como saber se o fornecedor está passando por um dia ruim. Ele lê o que o painel registra, e é honesto até onde o painel é honesto.

Por fim, um limite que costuma surpreender: cancelamento e reposição dependem do serviço, não do assistente. cancel_order só funciona se o serviço aceitar cancelamento e o pedido ainda não estiver concluído; se o serviço não aceitar, a ferramenta devolve um código dizendo que o cancelamento não é suportado. refill_order só funciona em pedido concluído e em serviço com garantia de reposição; ela é gratuita e não mexe no saldo. Nenhuma insistência na conversa muda esses critérios, e o texto sobre por que os seguidores caem e como funciona a reposição explica o motivo dessa regra existir.

Segurança: senha, tokens e prazos de validade

Todo segredo emitido pelo sistema tem prefixo próprio, tamanho fixo e prazo definido. A tabela abaixo é o mapa completo.

Segredo	Prefixo	Validade
Código de autorização	pf_mca_	10 minutos, uso único
Token de acesso	pf_mcp_	8 horas
Token de renovação	pf_mcr_	90 dias, rotacionado a cada uso
Identificador de cliente	mcpc_	sem prazo
Chave da API v3	pf_live_	vale até você revogar

Quatro fatos que vale conhecer sobre como esses segredos são tratados:

Todos são aleatórios de 256 bits. São 32 bytes de aleatoriedade codificados em base64url. Não há sequência previsível, contador ou dado da conta embutido no valor.

O banco de dados não guarda o valor em texto. Guarda apenas um resumo criptográfico HMAC-SHA256 do segredo, com uma chave de tempero derivada de uma variável de ambiente do servidor. Isso quer dizer que nem quem tem acesso ao banco consegue reconstruir um token. Também quer dizer que, se você perder a chave de API, ninguém pode recuperá-la para você: o caminho é gerar outra.

Reuso é tratado como incidente. Se um código de autorização for apresentado uma segunda vez, ou se chegar um token de renovação que já foi revogado, o sistema não apenas recusa aquela chamada: ele revoga todos os tokens daquele cliente para aquela conta. É a resposta padrão a um sinal de que alguém copiou um segredo. Você percebe porque o assistente perde o acesso de uma vez, e a solução é reconectar.

A rotação do token de renovação é automática. Cada uso devolve um token novo e invalida o anterior. Um cliente que funciona bem faz isso sozinho, sem você notar. O efeito prático é que o token de acesso de 8 horas se renova em silêncio, e a conexão dura até você desconectar.

Sobre o teto de requisições, para quem vai automatizar: o limite é de 600 requisições por minuto por conta, e é o mesmo teto da API v3, compartilhado. Não importa se as chamadas vieram do assistente ou do seu sistema, elas somam. Ao ultrapassar, a resposta é HTTP 429 com um cabeçalho pedindo que se espere 60 segundos. Existe ainda, na camada da API, um limite de 900 requisições por minuto por endereço IP.

Cada chamada fica registrada: o que o log de auditoria guarda?

Toda chamada de ferramenta é gravada em um registro de auditoria. Isso não é opcional e não depende de configuração. O objetivo é que, depois, seja possível responder à pergunta mais importante de qualquer automação: este pedido foi aberto pela IA ou por uma pessoa na tela?

Campo registrado	O que ele contém
Cliente	a identificação do aplicativo que chamou
Conta	o identificador da conta dona do token
Ferramenta	o nome da ferramenta chamada
Argumentos	os parâmetros enviados, com campos sensíveis mascarados
Resultado	a resposta, nas ferramentas de escrita
Erro	o código do erro, quando houve
Duração	quanto tempo a chamada levou

Três regras desse registro merecem destaque.

Campos sensíveis são mascarados. Qualquer argumento cujo nome pareça segredo (chave de API, senha, token, frase secreta) é substituído por asteriscos antes da gravação. Se um cliente mal configurado mandar uma credencial dentro de um parâmetro, ela não vai parar no registro em texto claro.

Resultado de leitura não é gravado. Só as ferramentas de escrita têm o resultado registrado. Ferramenta de leitura pode devolver uma lista com dezenas de serviços, e guardar isso a cada consulta encheria o registro de volume sem valor. O que importa auditar é o que mudou.

Tudo é cortado em tamanho. Os argumentos e o resultado são truncados em 8.000 caracteres na gravação, e a resposta que o modelo recebe é cortada em 100.000 caracteres. Isso protege contra uma resposta gigante travar a conversa ou inflar o banco.

Vale acrescentar que a gravação do registro é feita da melhor forma possível, mas não bloqueia a operação: se o registro falhar por algum motivo, o pedido do usuário continua funcionando. É a escolha certa em um sistema que lida com dinheiro, porque a alternativa seria recusar uma compra legítima por causa de um problema de log.

Como ver e desconectar os assistentes conectados?

O último cartão da página "Assistente de IA" se chama "Assistentes conectados" e é a sua central de controle. Enquanto você não tiver conectado nada, ele mostra "Nenhum assistente de IA conectado ainda.".

Cada linha da lista traz cinco informações:

Coluna	O que significa
Nome do cliente	como o aplicativo se identificou no cadastro
Selo de permissão	"Acesso total" ou "Somente leitura"
"Conectado"	a data em que a autorização foi dada
"Último uso"	a data da última chamada de ferramenta, ou "Nunca"
"Desconectar"	o botão que encerra o acesso

A coluna "Último uso" é mais útil do que parece. Ela responde à pergunta que aparece meses depois: "esse cliente aqui ainda serve para alguma coisa?". Uma linha com "Nunca" ou com data antiga é candidata natural a ser removida. Manter conexões ativas que ninguém usa é o equivalente digital de deixar cópias da chave de casa espalhadas.

Ao clicar em "Desconectar", aparece a confirmação "Este assistente vai perder o acesso à sua conta. Continuar?". Confirmando, o painel responde "Conexão encerrada." e a linha some da lista. Se algo der errado, a mensagem é "Não foi possível desconectar.".

O que acontece do lado do cliente depois disso? Na próxima chamada, ele recebe um erro de token inválido. Um cliente bem escrito tenta renovar, falha também, e mostra que precisa reautenticar. Não há período de carência: a revogação vale na hora, e ela derruba tanto o token de acesso quanto o de renovação daquela conexão. Os outros assistentes conectados continuam funcionando normalmente.

Existe ainda a revogação pelo lado do protocolo, no endereço /api/mcp/oauth/revoke, usada por clientes que fazem a limpeza sozinhos quando você remove o servidor da configuração deles. E vale lembrar: desconectar um cliente OAuth não mexe nas suas chaves de API. Se o seu assistente estava conectado por chave, o botão de desconectar não é o caminho; nesse caso você gera uma chave nova em /pt-br/dashboard/api, o que invalida a anterior.

Automação: como funcionam o fluxo de eventos e os webhooks?

Consultar status de tempos em tempos funciona, mas gasta requisição e sempre chega atrasado. Para quem automatiza de verdade, existem dois caminhos melhores, e ambos estão disponíveis nas ferramentas.

O primeiro é o fluxo de eventos. A ferramenta list_events devolve os eventos da conta em ordem cronológica, do mais antigo para o mais recente, e a leitura avança por cursor: você guarda a posição onde parou e continua dali na próxima vez. Nada se perde entre duas leituras, mesmo que o assistente fique horas sem consultar.

Tipo de evento	Quando ele aparece
order.created	um pedido foi criado
order.processing	o fornecedor começou a entregar
order.completed	a entrega foi concluída
order.partial	a entrega ficou incompleta
order.canceled	o pedido foi cancelado
order.updated	algum dado do pedido mudou
refill.created	uma reposição foi solicitada
refill.updated	o andamento da reposição mudou

Os nomes dos eventos não são traduzidos em idioma nenhum, o que é proposital: nome de evento é identificador, não texto de interface, e traduzir quebraria toda integração que depende dele.

O segundo caminho é o webhook: o painel avisa o seu sistema em vez de o seu sistema perguntar. Com create_webhook, o assistente cadastra um endereço e escolhe quais eventos quer receber; list_webhooks mostra o que está cadastrado; delete_webhook remove um endereço e derruba junto as entregas que ainda estavam na fila.

Um detalhe crítico: ao criar um webhook, o segredo de assinatura é mostrado uma única vez, na resposta daquela chamada. É com ele que o seu sistema confere se a notificação veio mesmo do painel. Se você perder, não há como recuperar: o caminho é apagar o webhook e criar outro. Se for o assistente que criou, peça para ele mostrar o segredo na hora e guarde em lugar seguro imediatamente.

Qual dos dois usar? A regra prática é ambiente. Se você tem um servidor com endereço público e certificado, webhook é melhor: chega na hora e não consome requisição. Se você desenvolve na sua máquina, se o seu IP muda, ou se você não quer manter um servidor de pé só para isso, o fluxo de eventos resolve o mesmo problema sem exigir infraestrutura. A documentação da API descreve o formato da assinatura e o comportamento de reenvio em detalhe.

Comandos prontos: order_status, find_service e reorder

Além das ferramentas, o servidor publica três comandos prontos. Eles são fluxos de trabalho já escritos: em vez de você formular o pedido perfeito, o cliente de IA oferece o comando em um menu, você escolhe, e o roteiro completo é entregue ao modelo.

Comando	O que ele faz	Argumentos
order_status	resume os pedidos recentes e destaca os que travaram ou ficaram incompletos	count (padrão 10)
find_service	compara de 3 a 5 serviços para um pedido seu e calcula o preço, sem comprar nada	request (obrigatório), quantity (opcional)
reorder	repete um pedido antigo, com a sua confirmação	order_id (obrigatório)

O mais usado no dia a dia costuma ser o order_status. Ele instrui o modelo a listar os pedidos com número, nome do serviço, status, quantidade, quantidade restante e valor, e a destacar separadamente o que não terminou ou apresentou erro do fornecedor, dizendo o que pode ser feito em cada caso (cancelar, pedir reposição, esperar). É a primeira coisa a rodar de manhã se você opera várias campanhas.

O find_service é o oposto do impulso de compra: ele explicitamente não abre pedido. O roteiro manda o modelo montar uma tabela comparativa por preço, faixa de quantidade, garantia de reposição e tempo médio, e, se você informou uma quantidade, calcular o valor pela prévia no serviço mais adequado. A decisão fica com você. É o comando certo quando você quer entender o catálogo antes de gastar, e ele funciona perfeitamente em uma conexão somente leitura.

O reorder cobre o caso mais comum de operação recorrente: você gostou de um pedido, quer o mesmo de novo. O roteiro lê o pedido antigo, refaz a prévia com o preço atual (que pode ter mudado desde então), mostra o valor e pede confirmação. Ele também avisa se ainda existe um pedido em andamento para o mesmo link, situação que costuma dar problema com o fornecedor.

Nem todo cliente de IA expõe comandos prontos na interface, e não há prejuízo nenhum se o seu não expõe: tudo que eles fazem pode ser pedido em linguagem normal. Eles são um atalho, não um recurso exclusivo.

O protocolo por dentro: versões, chamadas em lote e como os erros chegam ao modelo

Esta seção é para quem escreve o próprio cliente ou precisa depurar uma integração. Se você só quer usar um aplicativo pronto, pode pular.

O servidor fala JSON-RPC 2.0 sobre HTTP, sem estado. Não há identificador de sessão, não há conexão persistente, e cada requisição carrega tudo o que precisa. Os métodos atendidos são initialize, tools/list, tools/call, prompts/list, prompts/get, ping, resources/list e resources/templates/list. Os dois últimos existem por conformidade e devolvem lista vazia, porque este servidor não publica recursos.

A versão nativa do protocolo é a de 18 de junho de 2025, e as versões anteriores de 26 de março de 2025 e de 5 de novembro de 2024 também são aceitas. A negociação acontece no initialize: o cliente diz o que fala, o servidor responde com a versão em que os dois se entendem. Clientes mais antigos continuam funcionando sem ajuste.

Chamadas em lote são suportadas: você pode mandar um array de requisições em um único POST. E há um comportamento que confunde quem testa manualmente: um corpo que contenha apenas notificações recebe HTTP 202 sem corpo de resposta. Isso está correto por especificação, notificação não tem resposta, mas parece "não retornou nada" para quem esperava JSON.

O ponto mais interessante do desenho é como o erro de ferramenta é entregue. Erro de ferramenta não é erro de protocolo. Quando create_order falha por saldo insuficiente, o servidor não devolve um erro JSON-RPC: devolve uma resposta bem-sucedida contendo texto e uma marcação de erro. A diferença é enorme na prática, porque o modelo lê essa mensagem e pode se corrigir, em vez de o cliente engolir uma exceção e simplesmente parar.

Na prática, isso é o que permite conversas como esta: você pede 100 unidades de um serviço cujo mínimo é 500, a ferramenta devolve o erro de quantidade fora da faixa, e o assistente responde explicando o limite e perguntando se você quer 500. Sem esse desenho, você veria apenas "a chamada falhou".

Os códigos de erro são fixos e em inglês (insufficient_balance, quantity_out_of_range, cancel_not_supported e assim por diante), mas a mensagem legível vem no idioma da conta. A instrução do servidor manda o modelo repassar a mensagem como veio, sem inventar solução, o que é a atitude certa: um modelo que improvisa explicação para um erro de pagamento causa mais confusão do que ajuda.

O que muda para revendedores e donos de painel filho?

Se você revende com marca própria, o MCP passa a ser um recurso do seu produto, não só uma conveniência sua. Vale entender os dois lados.

Como cliente do Panel Follows, nada muda: você conecta o seu assistente ao endereço principal e opera a sua conta normalmente, com as mesmas 18 ferramentas.

Como dono de um painel filho, o servidor MCP existe no seu domínio, e os seus clientes conectam os assistentes deles a você. Aqui está o detalhe que torna isso viável em marca branca: todos os endereços do fluxo OAuth são gerados a partir da origem da requisição. Quando o cliente do seu painel inicia a conexão, o emissor declarado, o endereço de autorização, o endereço de token e o de registro são todos do seu domínio. O nome do painel principal não aparece em nenhum ponto do caminho, nem na tela de autorização, nem nos metadados que o cliente de IA lê.

As mesmas páginas funcionam para os seus clientes: o item "Assistente de IA" no menu, o cartão "Endereço de conexão" com o seu endereço, a lista "Assistentes conectados". A operação é idêntica, a marca é a sua.

Um ponto de atenção que gera chamado de suporte com frequência: uma conta criada em um painel filho vale apenas naquele domínio. Se o seu cliente tentar conectar o assistente ao endereço do painel principal com as credenciais dele, não vai funcionar, e a mensagem não vai dizer que o problema é o endereço. Deixe isso claro na sua documentação de cliente: o endereço de conexão é o do painel onde ele criou a conta.

Do ponto de vista comercial, poder dizer "o meu painel se conecta ao Claude e ao ChatGPT" é um diferencial concreto em um mercado onde a maioria dos painéis oferece apenas uma API de revendedor com o mesmo formato de sempre. Quem está montando essa operação encontra o resto do raciocínio no guia sobre como ser revendedor de painel SMM do zero, e a parte comercial do produto está na página do painel filho.

Para agências que operam contas de vários clientes, o cálculo é diferente e vale ser dito: o ganho não está na conversa fofa com a IA, está em reduzir o número de telas por tarefa repetida. Quem faz o mesmo ciclo de compra vinte vezes por semana sente a diferença na primeira semana. O artigo sobre como escalar uma agência de social media trata desse tipo de decisão de processo, e a página de painel SMM para agências mostra o desenho comercial.

Do lado do dono do painel: o servidor de administração com 57 ferramentas

Uma nota curta, para completar o quadro. O painel também é administrado pelo mesmo protocolo. O endereço é POST /api/mcp, a autenticação é uma única chave secreta definida no servidor, e são 57 ferramentas cobrindo visão geral, busca e auditoria, usuários, pedidos, solicitações de pedido, serviços, categorias, fornecedores, pagamentos, chamados de suporte, cupons e configurações.

Duas características desse servidor interessam também a quem é só cliente, porque falam sobre o cuidado do sistema como um todo. Primeira: se a chave secreta não estiver definida, o endereço fica completamente fechado e responde com HTTP 503. Não existe modo aberto por engano. Segunda: existem travas de consistência que nenhuma instrução de IA pode contornar, como a impossibilidade de rebaixar ou banir o último administrador ativo, e o fato de que operações que mexem em dinheiro rodam com transação e travamento de linha, de forma atômica.

E, como no servidor do usuário, cada chamada é gravada no registro de auditoria. A diferença é que ali o campo de conta fica vazio, o que permite distinguir uma ação de administração de uma ação de cliente na mesma tabela.

MCP, API ou painel: quando usar cada um?

Os três caminhos falam com o mesmo sistema e produzem os mesmos pedidos. A escolha é de ferramenta, não de resultado.

Situação	Melhor caminho	Por quê
Comprar uma vez, sabendo exatamente o que quer	Painel	é o menor número de passos
Comparar serviços parecidos antes de decidir	MCP	o assistente monta a comparação com dados reais
Integrar uma loja ou um sistema próprio	API v3	código determinístico, sem intermediário
Enviar centenas de pedidos por dia, automaticamente	API v3	previsível, testável, sem custo de conversa
Verificar o status da operação de manhã	MCP	um comando resume tudo
Deixar alguém monitorar sem poder comprar	MCP somente leitura	a restrição é aplicada pelo servidor
Receber avisos de mudança de status	Webhook	não gasta requisição e chega na hora

A frase que resume: use a API quando o fluxo é fixo e você o escreveu; use o MCP quando o fluxo é variável e a decisão é humana; use o painel quando você já sabe o que quer. Os três compartilham o mesmo teto de requisições por conta, e nada impede usar os três ao mesmo tempo, porque tudo aparece no mesmo lugar depois.

Vale notar uma vantagem de aprendizado: como as ferramentas do MCP espelham os endereços da API v3 e usam nomes de parâmetro idênticos, conversar com o assistente é uma forma de estudar a API. Você pode pedir para ele mostrar qual chamada faria antes de fazer, e o resultado é praticamente a documentação da rota traduzida para o seu caso. Quem for integrar depois encontra a referência completa em API para painel SMM e na documentação para desenvolvedores.

Solução de problemas: erros comuns e o que eles significam

Quase todo problema de conexão cai em um destes casos.

Sintoma	Causa	O que fazer
Erro de token inválido, com código 401	as 8 horas do token de acesso terminaram	o cliente renova sozinho com o token de renovação; se não renovar, reconecte pelo painel
HTTP 405 ao abrir o endereço no navegador	você tentou um GET, esperando um fluxo SSE	o protocolo só aceita POST, isso é comportamento normal
HTTP 429	o teto de 600 requisições por minuto foi ultrapassado	espere o tempo indicado no cabeçalho de resposta
"Este pedido de conexão é inválido ou expirou."	o código de autorização passou dos 10 minutos, ou o cliente não está cadastrado	recomece o fluxo pelo cliente de IA
O endereço de token responde 400	o cliente mandou PKCE no modo plain	apenas S256 é aceito, é regra do OAuth 2.1
O endereço de retorno é recusado	o redirect_uri não bate com o que foi registrado	a única flexibilidade é a porta do endereço local
Endereço de administração responde 503	a chave secreta do servidor de administração não está definida	isso só diz respeito ao dono do painel
A conta não é encontrada	conta criada em um painel filho, tentando conectar em outro domínio	conecte pelo endereço do painel onde a conta foi criada
A ferramenta de criar pedido não aparece	a conexão foi autorizada como "Somente leitura"	desconecte e conecte de novo sem marcar a caixa
O assistente diz que o serviço não aceita cancelamento	o serviço realmente não aceita	não é limitação da IA, é característica do serviço

Um roteiro de diagnóstico em três passos, quando nada disso resolve:

1. Teste o servidor sem o cliente. Rode a chamada de curl com uma chave de API e peça a lista de ferramentas. Se ela responder, o problema é do lado do cliente.
2. Confira o endereço. O caminho é /api/mcp/user, com barra e sem barra final extra, no domínio do painel onde você tem conta.
3. Olhe a lista de assistentes conectados. Se a linha não está lá, a autorização não foi concluída. Se está lá com "Somente leitura" e você esperava comprar, é isso.

Perguntas Frequentes

O que é MCP, em uma frase?

MCP é um protocolo aberto que padroniza a conversa entre assistentes de IA e sistemas externos, definindo como o sistema publica ferramentas e como o modelo as chama. No Panel Follows, ele expõe 18 ferramentas que dão acesso à sua própria conta: catálogo, preços, pedidos, reposição e automação. O assistente não adivinha nada, ele consulta o painel de verdade e usa a resposta.

Preciso dar a senha do painel para o assistente?

Não, em nenhuma hipótese. No fluxo OAuth, você digita a senha na página do Panel Follows, dentro do seu navegador, e o cliente de IA recebe apenas um token de acesso com validade de 8 horas. Na conexão por chave de API, a senha nem entra no caminho. A própria tela diz isso: a autorização acontece no painel e a senha nunca é compartilhada com o cliente.

O assistente pode fazer pedidos sem a minha autorização?

O servidor instrui o modelo a nunca chamar a ferramenta de criar pedido sem confirmação explícita, e o fluxo obrigatório passa antes por uma prévia que mostra o valor exato e o saldo restante. Se você quer uma garantia que não dependa do comportamento do modelo, autorize a conexão como "Somente leitura": nesse caso as seis ferramentas de escrita nem aparecem na lista, e o assistente não tem como chamá-las.

Quais aplicativos de IA funcionam com o painel?

Qualquer cliente que fale MCP sobre HTTP e suporte OAuth 2.1 com PKCE. Clientes que permitem enviar cabeçalhos personalizados também funcionam com uma chave de API, sem passar por navegador. A página de configuração do painel traz exemplos prontos para adicionar por linha de comando e para colar em um arquivo JSON de configuração.

Como desconecto um assistente e o que acontece depois?

Vá até a página "Assistente de IA", encontre a linha do cliente na lista "Assistentes conectados" e clique em "Desconectar", confirmando a pergunta que aparece. O acesso é cortado imediatamente, tanto o token de acesso quanto o de renovação daquela conexão deixam de valer, e o cliente passa a receber erro de token inválido. Os outros assistentes conectados continuam funcionando normalmente.

Por quanto tempo vale o acesso e vou precisar reconectar sempre?

O token de acesso vale 8 horas, mas você não sente isso: junto vem um token de renovação de 90 dias, trocado por um novo a cada uso, e o cliente renova sozinho em segundo plano. Na prática, a conexão dura até você clicar em "Desconectar". A exceção é o caso de reuso de segredo, que revoga todos os tokens daquele cliente por segurança e exige reconectar.

O assistente pode adicionar saldo na minha conta?

Não. Não existe ferramenta de pagamento, de saque ou de transferência no servidor. O assistente consegue ler o seu saldo disponível e avisar quando ele não é suficiente para o pedido, mas recarregar continua sendo uma ação sua, feita no painel, pelas formas de pagamento ativas. O mesmo vale para abrir chamado de suporte e alterar dados de cadastro.

Devo conectar por OAuth ou por chave de API?

Se o ambiente tem navegador, use OAuth: você não copia segredo nenhum, pode restringir a conexão a somente leitura e revogar aquele cliente específico com um clique. Se o ambiente não tem navegador (um servidor, um contêiner, um script agendado), use a chave de API pelo cabeçalho. Lembre que a conexão por chave é sempre de acesso total, porque a restrição de permissão só existe no fluxo OAuth.

Consigo ver no painel os pedidos que o assistente abriu?

Sim, eles aparecem em "Meus pedidos" exatamente como qualquer outro pedido, com o mesmo número, status e valor. Além disso, toda chamada de ferramenta é gravada no registro de auditoria com o nome da ferramenta, o cliente que chamou, os argumentos e o resultado, então é possível saber depois se um pedido foi aberto pela IA ou por uma pessoa na tela.

Os clientes de um painel filho também podem conectar assistentes?

Sim, com as mesmas páginas e as mesmas ferramentas, no domínio do painel filho. Todos os endereços do fluxo OAuth são gerados a partir da origem da requisição, então o emissor, a tela de autorização e os metadados ficam no domínio do revendedor, sem expor o painel principal. A conta, no entanto, vale só naquele domínio: quem criou conta em um painel filho precisa conectar pelo endereço daquele painel.

O que acontece quando uma ferramenta devolve erro?

O erro chega ao modelo como texto marcado como erro, não como falha de protocolo, o que permite que ele leia a mensagem e se corrija na mesma conversa. Os códigos são fixos e a mensagem legível vem no idioma da conta, e a instrução do servidor manda o assistente repassar essa mensagem como ela veio, sem inventar solução. Na prática, você recebe uma explicação do tipo "a quantidade está fora da faixa permitida" seguida de uma pergunta sobre como ajustar.

Usar MCP tem algum custo adicional?

Não há cobrança pela conexão, pela quantidade de ferramentas chamadas nem pelo tempo de uso. O que sai do seu saldo é o valor dos pedidos que você aprovar, exatamente o mesmo que sairia se você tivesse comprado pela tela. O que existe é um teto de requisições por minuto, compartilhado com a API, que serve para proteger o serviço e não para cobrar nada.

Um roteiro para o seu primeiro dia com o assistente

Se você quer um caminho curto para sair do zero e ainda assim não gastar errado, faça nesta ordem.

1. Conecte em modo somente leitura. Abra a página "Assistente de IA", copie o "Endereço de conexão", adicione no seu cliente e, na tela de autorização, marque a caixa de acesso somente leitura. Nada do que você fizer nesta etapa pode gastar dinheiro.
2. Peça uma leitura de conta. "Qual é o meu saldo?" é o teste mais rápido de que a conexão funciona de ponta a ponta.
3. Explore o catálogo. Peça uma comparação de serviços para algo que você compra com frequência, informando a quantidade. Confira se os números que ele apresenta batem com o que você vê na lista de serviços.
4. Rode o resumo de pedidos. Peça o status dos últimos pedidos e veja se o resumo é útil para a sua rotina.
5. Só então autorize a escrita. Desconecte, conecte de novo sem marcar a caixa, e faça um pedido de teste na quantidade mínima de um serviço que você conhece. Compare o valor da prévia com o valor cobrado.
6. Confira no painel. Abra "Meus pedidos" e veja o pedido aparecer lá, com o mesmo número que o assistente informou. É essa conferência que constrói confiança no processo.
7. Decida o que fica. Se a rotina funcionar, mantenha a conexão. Se não usar por semanas, remova pela lista "Assistentes conectados": conexão parada não deveria continuar aberta.

Duas recomendações que valem mais do que qualquer configuração. A primeira: leia sempre o valor da prévia antes de responder que sim. É o único momento em que a decisão é reversível, e ela leva dois segundos. A segunda: comece pequeno. A quantidade mínima em um serviço desconhecido é o teste mais barato que existe, e ele revela velocidade real e comportamento de queda antes de você comprometer orçamento, com IA ou sem IA.

No fim, o MCP não muda o que o painel faz. Ele muda quantas telas ficam entre a sua decisão e o pedido. As regras continuam as mesmas: o preço é o do catálogo, a reposição depende do serviço, o cancelamento depende do serviço, e o resultado depende do fornecedor. O que você ganha é velocidade nas partes repetitivas e uma forma mais direta de perguntar. Se ainda restou dúvida de operação, a página de perguntas frequentes cobre o resto, e quem ainda não tem conta começa pelo cadastro e pela lista de serviços.