MCP no painel SMM: ligar o assistente de IA à sua conta

O MCP (Model Context Protocol) é um protocolo aberto que permite a um assistente de IA falar diretamente com um sistema externo, e no Panel Follows significa que pode ligar o Claude, o ChatGPT ou outro cliente compatível à sua conta para procurar serviços, calcular preços, criar encomendas e acompanhar estados, sem lhe dar a palavra-passe do painel. A ligação faz-se uma vez, é autorizada dentro do painel e pode ser cortada com um clique a qualquer momento.

Este texto explica o mecanismo todo, do lado de quem usa. Não é uma apresentação comercial: é a descrição do que existe, do que não existe, e de onde é que as coisas costumam correr mal. Cada nome de botão, cada distintivo e cada mensagem que aqui aparece entre aspas está escrito exatamente assim no painel quando está em português.

Vale a pena dizer já ao que vem, porque é fácil ter a expectativa errada. Um assistente ligado por MCP não é um robô de crescimento nem um otimizador. Não escolhe estratégias por si, não garante resultados e não faz nada que você próprio não pudesse fazer no painel. O que faz é tirar-lhe o trabalho de navegação: em vez de abrir três ecrãs para comparar serviços e um quarto para confirmar o saldo, escreve a pergunta e recebe a tabela feita. A decisão de gastar dinheiro continua a ser sua, e o servidor está construído para que continue a ser sua.

O que vai encontrar a seguir: a definição do protocolo, a diferença entre os dois servidores MCP que o painel expõe, a lista completa das dezoito ferramentas a que o assistente acede, os três passos da ligação, o que o OAuth 2.1 faz nos bastidores, quando é que compensa usar uma chave de API, o que a opção "Apenas leitura" desliga na prática, a ordem obrigatória com que uma encomenda é criada, os limites reais, o registo de auditoria, os eventos e webhooks, e uma tabela de resolução de problemas com os erros que aparecem mesmo.

O que é o MCP e o que faz num painel SMM?

O MCP é um protocolo aberto que padroniza a forma como um modelo de linguagem chama funções de um sistema externo. Em vez de cada aplicação inventar o seu próprio formato, o servidor MCP publica uma lista de ferramentas, com nome, descrição e esquema de parâmetros, e o cliente de IA lê essa lista e sabe o que pode chamar. Toda a comunicação passa por JSON-RPC 2.0 sobre HTTP.

A parte que interessa aqui é a segunda metade da frase. Um servidor MCP não é uma API nova: é uma camada de descrição por cima de coisas que já existem. No Panel Follows, cada ferramenta MCP corresponde a um endpoint da API de programador v3, e os nomes dos parâmetros são exatamente os mesmos nos dois lados. Se já leu a documentação em documentação da API, não tem um segundo vocabulário para decorar: o campo chama-se service na API e chama-se service na ferramenta.

Traduzindo para o dia a dia de quem compra serviços de redes sociais (seguidores, gostos, visualizações, comentários), a diferença é esta. Sem MCP, para saber quanto custam cinco mil visualizações num serviço com reposição, abre o catálogo, filtra por plataforma, percorre a lista, compara três linhas, faz a conta de cabeça e confirma o saldo noutra página. Com MCP, escreve a pergunta ao assistente e ele executa as mesmas consultas por si, devolvendo o valor calculado pelo próprio painel, não estimado por ele.

Há um ponto técnico que evita mal-entendidos desde o início: o modelo não inventa os números. Quando o assistente lhe diz que uma encomenda custa determinado valor, esse valor veio de uma chamada real ao painel, feita com a sua conta, sobre o catálogo em vigor naquele momento. O modelo é a interface, não a fonte. É precisamente por isso que o servidor obriga o assistente a passar por uma ferramenta de pré-visualização antes de criar seja o que for.

E há um limite conceptual que convém interiorizar: o assistente vê apenas a sua conta. Não existe nenhuma ferramenta que lhe permita consultar outro utilizador, mexer em preços de catálogo, ver fornecedores ou aceder a qualquer parte administrativa. Essa separação não é uma regra escrita numa instrução que o modelo possa contornar; é a fronteira do próprio conjunto de ferramentas que lhe é entregue.

Para quem é que isto é útil na prática?

Este mecanismo compensa para quem repete o mesmo trabalho manual muitas vezes por semana e não compensa para quem faz uma encomenda por mês. É uma questão de volume e de repetição, não de sofisticação técnica.

Os perfis onde a diferença é visível são quatro. O primeiro é o gestor de várias contas de redes sociais, que precisa de comparar serviços com frequência e de vigiar dezenas de encomendas ao mesmo tempo. O segundo é a agência que trabalha com clientes e quer resumos rápidos do estado das encomendas sem entrar no painel a cada pedido, um cenário que o guia sobre escalar uma agência de redes sociais aborda pelo lado da organização interna. O terceiro é o revendedor que já tem uma integração pela API e quer uma camada conversacional por cima dela para as tarefas pontuais. O quarto é o utilizador que simplesmente prefere escrever "quanto custa isto" em vez de navegar.

Situação	O MCP ajuda?	Porquê
Uma encomenda por mês, sempre no mesmo serviço	Pouco	O formulário do painel é mais rápido do que configurar um cliente
Comparar serviços antes de cada compra	Muito	O assistente filtra, compara e calcula numa só resposta
Vigiar dezenas de encomendas em curso	Muito	Uma pergunta substitui a leitura da tabela inteira
Integração automática já a funcionar pela API	Complementar	O MCP serve para as tarefas manuais, não substitui o código
Necessidade de carregar saldo ou levantar dinheiro	Nada	Essas operações não existem nas ferramentas

Há também um caso em que o MCP é claramente a escolha errada: automatismos que têm de correr sozinhos, sem ninguém a ler as respostas. Se quer um processo que cria encomendas todas as noites a partir de uma folha de cálculo, escreva-o contra a API v3 diretamente. Um modelo de linguagem no meio de um circuito automático acrescenta latência, custo e imprevisibilidade sem acrescentar valor nenhum.

Por fim, uma nota sobre expectativas de qualidade. Ligar um assistente não muda nada na entrega: os serviços são os mesmos, os fornecedores são os mesmos, os prazos são os mesmos e as regras de reposição e cancelamento são exatamente as que já valiam. Se um serviço não tem reposição, continua a não ter quando é encomendado por IA. O artigo sobre por que caem os seguidores e como funciona a reposição continua a valer palavra por palavra.

Dois servidores MCP no mesmo painel: qual é o seu?

O painel expõe dois servidores MCP diferentes, com endereços diferentes, e é importante não os confundir: um é para clientes, o outro é para quem administra a plataforma.

	Servidor de conta	Servidor de gestão
Endereço	POST /api/mcp/user	POST /api/mcp
Quem se liga	o cliente do painel	o proprietário do painel
Identificação	token OAuth 2.1 ou chave de API da conta	uma única chave secreta do servidor
Alcance	apenas a própria conta, 18 ferramentas	a plataforma inteira, 57 ferramentas
Registo de auditoria	com identificação do utilizador	sem identificação de utilizador

O que interessa a quem está a ler este guia é o primeiro, o servidor de conta, em /api/mcp/user. Está sempre ligado a uma conta única e concreta: a que autorizou a ligação. Não há forma de, a partir dele, chegar aos dados de outra pessoa, mudar um preço de catálogo, ver o custo de um fornecedor ou tocar em qualquer definição da plataforma.

Os dois servidores partilham o mesmo núcleo de transporte, o que na prática significa que se comportam da mesma maneira em tudo o que é protocolo: mesma versão, mesmos métodos aceites, mesma forma de devolver erros, mesmo registo de auditoria. A diferença está no conjunto de ferramentas e na forma de autenticação, não na mecânica.

Uma consequência prática desta arquitetura merece destaque, porque tranquiliza quem se preocupa com segurança: mesmo que alguém descubra o endereço do servidor de gestão, esse endereço exige uma chave secreta do servidor que nunca sai dele e que não tem relação nenhuma com contas de clientes. E se essa chave não estiver definida no ambiente, o endpoint responde com um erro de serviço indisponível e não faz absolutamente nada, o que é o comportamento correto para uma superfície administrativa.

Quais são as 18 ferramentas a que o assistente acede?

O servidor de conta publica dezoito ferramentas, agrupadas em cinco áreas. Esta é a lista completa e os nomes são literais, tal como o assistente os vê.

Área	Ferramentas
Conta	get_account
Catálogo	list_platforms, list_categories, search_services, get_service
Encomendas	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 destas ferramentas apenas leem dados e seis escrevem. As de leitura são 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. As de escrita são create_order, create_orders_bulk, cancel_order, refill_order, create_webhook e delete_webhook.

Esta separação não é decorativa. Cada ferramenta é anunciada ao cliente de IA com duas indicações: se é apenas de leitura e se é destrutiva. As marcadas como destrutivas são create_order, create_orders_bulk, cancel_order e delete_webhook, ou seja, aquelas cujo efeito não se desfaz. As duas restantes de escrita, refill_order e create_webhook, escrevem mas não são destrutivas. Clientes de IA bem comportados usam estas indicações para pedir confirmação antes de executar.

Vale a pena olhar com atenção para algumas delas, porque o comportamento tem detalhes que fazem diferença:

• get_account devolve a identificação da conta, o e-mail, o saldo disponível em USD e o limite de pedidos. É a ferramenta que o assistente usa para confirmar que tem dinheiro antes de sugerir uma compra.
• search_services aceita os filtros search, platform, category, type, refill, cancel, dripfeed, min_rate e max_rate. Devolve 20 resultados por omissão e no máximo 50. É aqui que o assistente encontra o número do serviço.
• get_service dá o preço, os limites mínimo e máximo, se há reposição, se há cancelamento, se há entrega gradual, o tempo médio e, sobretudo, a lista de campos que aquela encomenda exige. O modelo não adivinha os campos obrigatórios: lê-os aqui.
• preview_order valida a encomenda sem a criar e devolve o valor a cobrar, o saldo que ficaria depois e se o saldo chega. É a peça central de todo o fluxo.
• create_order gasta dinheiro real e não se desfaz.
• create_orders_bulk aceita no máximo 50 encomendas por chamada. Os itens são processados por ordem e, se um falhar, os restantes continuam: cada item devolve o seu próprio resultado.
• list_orders filtra por estado, com os valores pending, in_progress, completed, partial, canceled, refunded e failed. Devolve 20 registos por omissão e no máximo 100.
• cancel_order só funciona se o serviço suportar cancelamento e a encomenda ainda não estiver concluída. Se o serviço não suportar, devolve o código cancel_not_supported.
• refill_order só funciona em encomendas concluídas e em serviços com reposição. Não custa nada e não mexe no saldo.
• create_webhook mostra o segredo de assinatura uma única vez, na resposta. Se o perder, cria outro.
• delete_webhook apaga também as entregas que estavam pendentes.

As ferramentas de listagem são paginadas por cursor: envia-se starting_after e a resposta traz next_cursor para a página seguinte. Isto tem uma razão de ser prática: cada resultado entra no contexto do modelo como texto, e páginas gigantes seriam caras e pouco úteis.

Um pormenor que poupa tempo a quem já usa a API: os nomes dos parâmetros de encomenda são idênticos aos da v3. São eles service, link, quantity, runs, interval, comments, username, posts, min, max, usernames, hashtag, hashtags, answer_number, groups, keywords e media. Um exemplo que funciona na documentação funciona também aqui.

Como ligar o assistente à sua conta em três passos

A página do painel chama-se "Assistente IA" no menu lateral e fica em /dashboard/mcp. O título da página é "Ligue o seu assistente de IA" e a primeira caixa é o "Endereço de ligação", com um botão "Copiar" ao lado.

Os três passos que a própria página descreve são estes:

1. Copie o endereço e adicione-o ao cliente de IA como servidor MCP. O endereço é o do servidor de conta, /api/mcp/user, no domínio onde tem a conta.
2. O cliente encaminha-o para aqui; autorize a ligação (apenas leitura, se preferir). Abre-se o navegador, aparece o ecrã de autorização do painel e é aí que decide.
3. A partir daí pode falar normalmente. A página sugere exemplos como "mostra-me preços de seguidores no Instagram" ou "como estão as minhas encomendas recentes".

Por baixo do endereço, a nota do painel é explícita quanto ao ponto que mais preocupa as pessoas: "Adicione este endereço ao seu cliente de IA. A autorização é dada aqui, no painel; a sua palavra-passe nunca é partilhada com o cliente." Não existe, em parte nenhuma deste fluxo, um passo em que escreva a palavra-passe da conta dentro do cliente de IA. Se algum cliente lhe pedir isso, não é este mecanismo que está a usar.

A página tem quatro secções, sempre pela mesma ordem: o "Endereço de ligação" com os três passos, a "Configuração por cliente" com os exemplos prontos a copiar, a caixa "O que o assistente pode fazer" com os limites, e por fim a lista "Assistentes ligados". Enquanto não tiver nada ligado, essa última secção mostra "Ainda não há nenhum assistente de IA ligado."

Se preferir o outro caminho, o da chave, a página tem uma linha curta a apontá-lo: "Prefere ligar-se com uma chave? Crie-a aqui:" seguida do link "Chaves de API", que leva à página de chaves e integrações. Mais à frente há uma secção inteira a comparar os dois caminhos.

Configuração por cliente: comando, ficheiro e cabeçalho

A secção "Configuração por cliente" do painel existe porque cada cliente de IA se configura de maneira diferente, e a nota que a acompanha resume a regra: "Funciona com qualquer cliente MCP com OAuth 2.1. Clientes que enviam cabeçalhos podem usar uma chave de API."

Para clientes com linha de comandos, o formato é um comando único:

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

Para clientes que se configuram por ficheiro, a entrada tem esta forma:

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

Se em vez de OAuth quiser usar uma chave de API, acrescenta-se o cabeçalho de autorização:

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

E, para testar sem cliente nenhum, um pedido direto com curl mostra a lista de 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"}'

Três observações sobre estes exemplos. Primeira: o transporte é HTTP simples, não é uma ligação persistente, o que significa que qualquer cliente capaz de fazer pedidos HTTP consegue falar com o servidor. Segunda: o nome panel é apenas a etiqueta local do servidor dentro do cliente, pode chamar-lhe o que quiser. Terceira: se está num painel com domínio próprio, substitua o domínio do exemplo pelo seu, porque o endereço tem de ser o do painel onde a conta existe.

Um erro comum de configuração vale um aviso antecipado: colar o endereço do servidor de gestão, /api/mcp, em vez do de conta, /api/mcp/user. São endereços parecidos e fazem coisas completamente diferentes. O de gestão não aceita nem tokens OAuth nem chaves de conta, por isso a ligação simplesmente não se estabelece, sem que seja evidente porquê.

O que o OAuth 2.1 faz nos bastidores, passo a passo

Todo o processo de autorização segue o OAuth 2.1 com PKCE, e o interesse de perceber o que se passa é simples: assim sabe exatamente em que ponto é que os seus dados entram e onde é que não entram.

1. O cliente faz um pedido sem identificação e recebe um 401. A resposta não é uma porta fechada: traz um cabeçalho WWW-Authenticate que aponta para o endereço dos metadados do recurso protegido, seguindo a RFC 9728. É assim que o cliente descobre sozinho como se deve autenticar.
2. O cliente lê os documentos de descoberta. Primeiro /.well-known/oauth-protected-resource, que identifica o recurso, e depois /.well-known/oauth-authorization-server, que descreve o servidor de autorização segundo a RFC 8414.
3. O cliente regista-se sozinho. Faz um pedido a /api/mcp/oauth/register, o registo dinâmico de clientes da RFC 7591, e recebe uma identificação própria. É um cliente público, sem segredo, e é por isso que a prova de posse é feita por PKCE. Este registo está limitado a 10 tentativas por hora e por endereço de origem.
4. Abre-se o navegador. O cliente encaminha-o para /api/mcp/oauth/authorize, que por sua vez o leva ao ecrã de autorização do painel, no endereço /mcp/connect. Se não tiver sessão iniciada, é enviado primeiro para o início de sessão e regressa ao mesmo ecrã depois de entrar.
5. Você autoriza. Aqui, e só aqui, decide se dá acesso total ou se marca a caixa de apenas leitura.
6. O cliente troca o código por um token. Faz um pedido a /api/mcp/oauth/token com o verificador de PKCE. Só é aceite o método S256; o método plain é recusado, como manda o OAuth 2.1.

O documento de descoberta anuncia com precisão o que o servidor suporta, e isso é útil para quem está a depurar uma ligação que não funciona:

Campo anunciado	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)

Sobre os endereços de retorno, há regras estritas e não negociáveis. São aceites endereços https, endereços locais em http para 127.0.0.1 e localhost, e esquemas próprios de aplicações, como cursor:// ou vscode://. O que é recusado é http simples para um endereço remoto, porque isso exporia o código de autorização em trânsito. O endereço usado tem de corresponder ao que foi registado, e a única flexibilidade permitida é o número da porta em ligações locais, conforme a RFC 8252.

Um detalhe de arquitetura com consequências para revendedores: os endereços anunciados são gerados a partir da origem do próprio pedido. Quando um cliente de um painel com domínio próprio se liga a partir desse domínio, o emissor anunciado é esse domínio. O endereço do painel principal não aparece em lado nenhum do processo, o que mantém a marca branca intacta de ponta a ponta.

Por fim, o verificador de PKCE tem de ter entre 43 e 128 caracteres. É uma exigência do próprio protocolo e não algo que tenha de configurar: qualquer cliente que implemente PKCE corretamente já cumpre isto.

Quando compensa ligar com uma chave de API em vez de OAuth?

Nem todos os clientes de IA implementam OAuth, e por isso o servidor aceita também autenticação por chave, exatamente a mesma que já usa na API de programador.

São aceites três formatos no cabeçalho Authorization: Bearer: um token OAuth com o prefixo pf_mcp_, uma chave da API v3 com o prefixo pf_live_, e uma chave de revendedor mais antiga, com 64 dígitos hexadecimais. O cabeçalho X-Api-Key também é aceite. O servidor distingue o caminho usado apenas pelo prefixo do valor recebido.

	OAuth 2.1	Chave de API
Onde autoriza	no ecrã do painel, com sessão iniciada	no ficheiro de configuração do cliente
A chave fica no disco do cliente	não, fica um token que expira	sim, em texto
Permissão limitada a leitura	sim, se marcar a caixa	não, é sempre acesso total
Validade	8 horas, renovada automaticamente	até a revogar
Aparece em "Assistentes ligados"	sim, com nome e datas	não
Como se corta	botão "Terminar ligação" no painel	regenerando a chave
Bom para	clientes de IA do dia a dia	scripts, ferramentas próprias, clientes sem OAuth

A regra de decisão é curta. Se o seu cliente suporta OAuth, use OAuth: é mais seguro, é revogável a partir do painel e permite dar apenas leitura. Se o cliente não suporta OAuth mas consegue enviar um cabeçalho, use a chave, com a consciência de que uma ligação por chave é sempre uma ligação com acesso total, porque a restrição de permissões só existe no OAuth.

Uma precaução vale a pena. Uma chave de API guardada num ficheiro de configuração é um segredo em texto simples no seu computador. Trate-a como trataria uma palavra-passe: não a partilhe em capturas de ecrã, não a cole em conversas e, se suspeitar de exposição, gere outra na página de chaves de API. Regenerar invalida a anterior imediatamente, o que também parte as integrações que a estivessem a usar.

O que vê no ecrã de autorização e o que está a autorizar

O ecrã de autorização fica no endereço /mcp/connect e é o único ponto do processo onde a decisão é sua. Não é uma página que se visite por vontade própria: só faz sentido quando é um cliente de IA que o encaminha para lá, e está marcada para não ser indexada pelos motores de busca.

O título mostra o nome do cliente que está a pedir acesso, no formato "{nome} quer ligar-se à sua conta", e por baixo aparece a frase "Se autorizar, esta aplicação pode fazer o seguinte em seu nome." Depois disso, o ecrã apresenta quatro blocos de informação e três controlos.

Elemento no ecrã	O que mostra
Nome do cliente	quem está a pedir a ligação, no título
"Conta"	o e-mail da conta que vai ser ligada
"Vai encaminhar para"	o endereço de retorno registado pelo cliente
Lista de permissões	o que a aplicação vai poder fazer em seu nome
"Dar acesso apenas de leitura (sem criar encomendas)"	caixa opcional que limita a ligação
"Autorizar ligação"	confirma e devolve o controlo ao cliente
"Recusar"	cancela sem autorizar nada

Vale a pena parar dois segundos em dois destes campos. O primeiro é "Conta": confirme que é mesmo o e-mail que espera, sobretudo se tiver mais do que uma conta. O segundo é "Vai encaminhar para": esse é o endereço para onde o código de autorização vai ser devolvido. Se estiver a instalar um cliente local, o normal é ver um endereço de localhost ou um esquema próprio da aplicação. Se vir um domínio que não reconhece, recuse.

Depois de carregar em "Autorizar ligação", o ecrã mostra brevemente "A encaminhar…" e devolve o controlo ao cliente de IA, que termina a troca sozinho. Não tem de copiar nem colar nada.

Duas mensagens de erro podem aparecer neste ecrã. A primeira é "O pedido de ligação é inválido ou expirou. Comece de novo a partir do cliente.", e significa exatamente o que diz: o pedido perdeu a validade ou o cliente não está registado. A segunda é "Não foi possível concluir a operação. Tente novamente.", um erro genérico. Em ambos os casos a solução é reiniciar o processo a partir do cliente de IA, nunca recarregando a página de autorização.

O que a opção "Apenas leitura" desliga exatamente?

A caixa "Dar acesso apenas de leitura (sem criar encomendas)" não é um aviso simpático nem uma sugestão ao modelo: é uma alteração real e verificável no conjunto de ferramentas que o assistente recebe.

Quando marca essa caixa, o token emitido leva apenas a permissão de leitura, e o servidor deixa de mostrar as seis ferramentas de escrita naquela ligação. Não é que o assistente seja instruído a não as chamar: elas não constam da lista que ele lê no arranque. Para o modelo, create_order deixa simplesmente de existir naquela sessão.

Esta escolha de implementação tem uma razão que vale a pena explicar, porque é o argumento central de confiança neste mecanismo. Escrever numa instrução "não chames esta ferramenta" transfere a responsabilidade para o comportamento do modelo, e o comportamento de um modelo não é uma garantia técnica. Retirar a ferramenta da lista transforma uma regra de conduta numa impossibilidade. É a diferença entre pedir a alguém que não abra uma gaveta e não lhe dar a chave.

	Acesso total	Apenas leitura
Procurar serviços e ver preços	sim	sim
Ver saldo, encomendas e reposições	sim	sim
Calcular o valor de uma encomenda	sim	sim
Criar uma encomenda	sim	ferramenta ausente
Criar encomendas em lote	sim	ferramenta ausente
Cancelar uma encomenda	sim	ferramenta ausente
Pedir reposição	sim	ferramenta ausente
Criar ou apagar um webhook	sim	ferramenta ausente
Distintivo na lista do painel	"Acesso total"	"Apenas leitura"

Além de filtrar as ferramentas, o servidor acrescenta uma nota às instruções que entrega ao modelo, a dizer que aquela ligação é de leitura e que o utilizador terá de retirar a limitação no painel se quiser encomendar. Isto evita a situação irritante em que o assistente tenta uma operação, falha e não sabe explicar porquê.

Uma nota sobre permissões que raramente é dita: se o cliente não pedir permissão nenhuma no momento da autorização, são concedidas as duas, leitura e escrita. E se pedir permissões que o servidor não reconhece, como as típicas de identidade em serviços de início de sessão, essas são simplesmente ignoradas, sem falhar o pedido.

Recomendação prática, sem dramatismos: comece por uma ligação de apenas leitura. Passe uma semana a fazer perguntas, a comparar serviços e a acompanhar encomendas. Quando confiar no fluxo e souber como o assistente se comporta, corte a ligação e volte a ligar com acesso total. Custa dois minutos e elimina a categoria inteira de enganos caros do período de aprendizagem.

Por que ordem é que o assistente cria uma encomenda?

O servidor entrega ao modelo uma instrução com uma sequência obrigatória de cinco passos, e essa sequência existe por uma razão muito concreta: uma ferramenta que gasta dinheiro chamada na ordem errada custa dinheiro a quem está do outro lado.

1. Encontrar o serviço. O assistente usa search_services, com a plataforma, a categoria ou o texto de pesquisa, e anota o número do serviço.
2. Ler a ficha. Com get_service, obtém os limites mínimo e máximo, se há reposição, se há cancelamento, o tempo médio e a lista de campos obrigatórios daquele serviço em concreto.
3. Calcular o valor. Com preview_order, obtém o valor a cobrar e a indicação de se o saldo chega, e é obrigado a dizer-lhe esses dois números de forma clara.
4. Pedir a sua autorização explícita. A instrução é direta: sem confirmação, não pode chamar create_order, porque a encomenda gasta dinheiro real e não se desfaz.
5. Criar a encomenda. Só então usa create_order e comunica-lhe o número da encomenda.

Na prática, uma conversa típica corre assim. Você pede uma comparação de serviços para uma plataforma; o assistente devolve três ou quatro opções com preço, limites e indicação de reposição; escolhe uma e indica a quantidade; ele calcula e diz-lhe o valor exato e o saldo que ficaria; você confirma; ele cria a encomenda e devolve o número. Do princípio ao fim, houve uma pergunta de confirmação antes de qualquer débito.

Há uma vantagem escondida no passo 3 que vale mais do que parece. A pré-visualização valida a encomenda inteira contra as regras reais do painel, sem a criar. Se a quantidade estiver fora dos limites, se faltar um campo obrigatório ou se o saldo não chegar, você fica a saber antes de qualquer coisa acontecer. É o equivalente conversacional a preencher o formulário do painel e olhar para a linha do total antes de carregar no botão, um hábito que o guia como usar o Panel Follows recomenda pela mesma razão.

Um aviso honesto sobre os limites desta proteção. A sequência é imposta por instrução ao modelo, não por uma barreira técnica: um cliente mal configurado, ou um modelo mal orientado, pode teoricamente chamar create_order diretamente. O que a impede de ser um problema real é a combinação de três coisas: a ferramenta está marcada como destrutiva, os clientes de IA sérios pedem confirmação antes de executar ferramentas destrutivas, e existe a opção de apenas leitura para quem não quer correr o risco de todo. Se essa possibilidade o incomoda, use apenas leitura e crie as encomendas no painel.

O erro de preço que custa mil vezes mais: per_1000 contra per_order

Este é, de longe, o ponto onde uma leitura descuidada faz o maior estrago, e por isso está escrito de forma explícita nas instruções que o servidor entrega ao modelo.

A esmagadora maioria dos serviços, sejam seguidores, gostos ou visualizações, tem preço por mil unidades. A resposta indica isso no campo de unidade de preço, com o valor per_1000, e a conta é a esperada: divide-se o preço por mil e multiplica-se pela quantidade. Mas existe uma família de serviços vendidos como pacote, em que o preço apresentado é o do pacote completo. Nesses, a unidade é per_order e a conta é outra: o preço é o preço, sem divisão nenhuma.

Unidade indicada	O que o número significa	Como se calcula
per_1000	preço por cada mil unidades	preço dividido por 1000, multiplicado pela quantidade
per_order	preço do pacote completo	é o próprio preço, sem multiplicação

Ignorar esta distinção não produz um erro pequeno: produz um erro de mil vezes, para cima ou para baixo. É o género de engano que passa despercebido numa conversa rápida, porque o número continua a parecer plausível se não estiver a comparar.

A boa notícia é que não tem de fazer estas contas. A ferramenta preview_order devolve o valor calculado pelo próprio painel, com as regras corretas aplicadas, incluindo esta. Sempre que houver dúvida entre o que o assistente disse e o que a pré-visualização mostrou, é a pré-visualização que manda, porque é ela que corresponde ao que será efetivamente debitado.

Há mais dois detalhes de leitura de números que o servidor deixa explícitos ao modelo e que convém conhecer. O primeiro: os valores são em dólares americanos e são devolvidos como texto decimal, precisamente para não serem convertidos para vírgula flutuante e arredondados pelo caminho. O segundo: se tem o painel a mostrar euros, essa é uma camada de apresentação sobre uma base em dólares, e o assistente trabalha sobre a base. Se está a fazer contas de margem para revenda, faça-as em dólares.

Uma última recomendação, simples e eficaz: confirme sempre a ordem de grandeza. Se esperava gastar cerca de dez unidades de moeda e o valor apresentado está em cêntimos, ou o contrário, pare e peça ao assistente que mostre outra vez a pré-visualização e a ficha do serviço. Uma pergunta a mais custa dois segundos; uma encomenda errada custa dinheiro.

Encomendas em lote, entrega gradual e tipos especiais

Nem todas as encomendas são iguais, e o assistente lida com as variações através dos mesmos campos que existem na API. Vale a pena saber o que esperar em cada caso, porque as regras não mudam por a encomenda ter sido criada por IA.

Encomendas em lote. A ferramenta create_orders_bulk aceita no máximo cinquenta encomendas por chamada. Os itens são processados por ordem, um a um, e um item que falhe não impede os seguintes: cada um devolve o seu próprio resultado, com sucesso ou com erro. Na prática, isto quer dizer que um lote de cinquenta linhas com três erros cria quarenta e sete encomendas e devolve três explicações. Peça sempre ao assistente para lhe mostrar o resumo linha a linha antes de dar por concluída a operação.

Entrega gradual. Os campos são runs, o número de repetições, e interval, os minutos entre repetições. Só funcionam em serviços que suportem entrega gradual, e a ficha obtida por get_service diz se é o caso. A regra que apanha toda a gente é a mesma que existe no painel: a quantidade passa a ser por lote, não o total. Se pedir mil unidades com cinco repetições, encomendou cinco mil e paga cinco mil. O artigo sobre entrega gradual e serviços automáticos explica quando é que este modo compensa e quando é apenas complicação.

Serviços de comentários. Nestes não se envia quantidade. Escreve-se um comentário por linha no campo próprio, e o número de linhas define a quantidade e, com ela, o preço. As instruções dadas ao modelo dizem isto explicitamente, para que não tente enviar um número de unidades onde ele não é aceite.

Tipos com campos adicionais. Há serviços que pedem nome de utilizador, lista de nomes, uma etiqueta, várias etiquetas, o número de uma opção de sondagem, ligações de grupos, palavras-chave ou uma ligação de conteúdo de origem. Os nomes dos campos são username, usernames, hashtag, hashtags, answer_number, groups, keywords e media. Nos serviços de subscrição, os campos são username, posts, min e max.

Família de serviço	Campos envolvidos	Como se define a quantidade
Normal	service, link, quantity	pelo campo de quantidade
Entrega gradual	mais runs e interval	quantidade por lote, multiplicada pelas repetições
Comentários	comments	pelo número de linhas escritas
Subscrição	username, posts, min, max	pelo máximo por publicação e número de publicações
Menções, sondagens, grupos, SEO	campos próprios do tipo	pelo campo de quantidade, salvo indicação da ficha

O ponto que resolve todos estes casos de uma vez: não tente adivinhar os campos. A ficha devolvida por get_service traz a lista de campos exigidos por aquele serviço em concreto, e o assistente foi instruído a lê-la antes de montar a encomenda. Se estiver a compor um pedido manualmente para testar, faça o mesmo.

O que o assistente não consegue fazer

A caixa "O que o assistente pode fazer", no painel, tem três linhas, e a terceira é a mais importante de todas. Vale a pena citá-la na íntegra: "Não pode carregar saldo, levantar dinheiro, ver a sua palavra-passe nem aceder a outras contas."

Estas não são promessas de intenção. São consequências de não existirem ferramentas para essas operações. Não há uma ferramenta de carregamento de saldo, não há uma de levantamento, não há nenhuma que devolva credenciais e não há nenhuma que aceite um identificador de outro utilizador. A lista das dezoito ferramentas é a fronteira completa do que é possível.

A lista concreta do que fica de fora:

• Carregar saldo. Qualquer operação de pagamento é feita no painel, com os métodos habituais. O assistente pode dizer-lhe que o saldo não chega, mas não pode resolvê-lo.
• Levantar dinheiro ou transferir saldo. Não existe.
• Mudar preços. Os preços do catálogo pertencem à plataforma. Num painel com marca própria, a margem é definida pelo proprietário do painel, no painel dele.
• Abrir pedidos de suporte. O assistente não abre nem responde a pedidos de suporte. Se precisar de ajuda humana, use a página de suporte ou a página de contactos.
• Ver a palavra-passe ou dados de autenticação. Não há ferramenta que devolva credenciais, e a palavra-passe nunca entra no fluxo de ligação.
• Aceder a outra conta. O servidor está ligado a uma conta fixa em cada pedido, determinada pelo token ou pela chave.
• Alterar definições da conta. Idioma, moeda, verificação em dois passos e perfil continuam a ser mexidos no painel.
• Ver fornecedores, custos internos ou dados de outros utilizadores. Isso pertence ao lado administrativo, que é outro servidor com outra autenticação.

Uma limitação adicional, de natureza diferente mas com o mesmo efeito prático: o assistente não pode contornar regras de serviço. Se um serviço não tem reposição, refill_order devolve um erro. Se não suporta cancelamento, cancel_order devolve o código cancel_not_supported. Se a quantidade está fora dos limites, a encomenda é recusada. Nenhuma destas regras se negoceia por conversa.

E uma nota de honestidade sobre o que o assistente também não faz, embora possa parecer que sim: não valida se o perfil de destino é público, não confirma que o nome de utilizador ainda é o mesmo e não verifica se a publicação existe. Isso não é uma limitação do MCP, é o comportamento do painel, e não muda por a encomenda vir de uma IA. A responsabilidade pela ligação colada continua a ser sua.

Segurança: prazos, segredos e o que fica guardado

Toda a autorização assenta em segredos com prazo curto e em armazenamento que não guarda o segredo em si. Esta é a tabela completa.

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, roda a cada utilização
Identificação do cliente	mcpc_	sem prazo
Chave da API v3	pf_live_	até ser revogada

Todos estes valores são gerados com 32 bytes de aleatoriedade, ou seja, 256 bits, e codificados em base64url. Na base de dados fica guardada apenas a impressão criptográfica de cada um, calculada com HMAC-SHA256: o valor em texto não é guardado em lado nenhum. Isso tem uma consequência que é preciso interiorizar: se perder um segredo, não há forma de o recuperar, só de gerar outro. É também a razão pela qual o segredo de assinatura de um webhook é mostrado uma única vez.

Há ainda uma proteção contra reutilização que merece explicação, porque o comportamento pode surpreender. Se um código de autorização for usado uma segunda vez, ou se aparecer um token de renovação que já tinha sido revogado, o servidor não se limita a recusar o pedido: revoga todos os tokens daquele cliente para aquela conta. A lógica é a habitual em OAuth: a reutilização de um segredo de uso único é um sinal de que ele pode ter sido copiado, e nesse cenário a resposta correta é cortar tudo e obrigar a nova autorização.

O que isto significa para si, no dia a dia, é simples. Se um cliente de IA de repente deixa de conseguir aceder e o painel já não o mostra em "Assistentes ligados", o mais provável é que uma reutilização tenha sido detetada. A solução é voltar a ligar a partir do cliente, o que reinicia o processo do zero.

Três hábitos que fazem a diferença e não custam nada: ligue apenas os clientes que reconhece, confira sempre o campo "Vai encaminhar para" no ecrã de autorização, e reveja de tempos a tempos a lista de assistentes ligados para cortar o que já não usa. Uma ligação esquecida não é perigosa por si só, mas é uma porta aberta que não serve para nada.

Cada chamada fica registada: o registo de auditoria

Todas as chamadas de ferramenta, sem exceção, são escritas num registo de auditoria interno. Isto vale tanto para o servidor de conta como para o de gestão, e a distinção entre os dois faz-se pela presença ou ausência da identificação do utilizador.

O que fica guardado em cada linha: o cliente que fez a chamada, identificado pelo cabeçalho de agente, a conta envolvida, o nome da ferramenta, os argumentos recebidos, o resultado, o erro caso tenha havido, e a duração da chamada em milissegundos.

Três regras moldam o que entra no registo, e todas têm uma razão prática:

1. Campos com aspeto de segredo são mascarados. Argumentos com nomes como chave de API, segredo, palavra-passe, frase de acesso ou token são substituídos por asteriscos antes de serem gravados. O registo não é um sítio onde credenciais devam ficar.
2. O resultado das ferramentas de leitura não é guardado. Uma listagem de serviços ocuparia muito espaço e não acrescentaria informação útil a uma auditoria. Já o resultado das ferramentas de escrita é guardado, porque é aí que está o que interessa reconstituir.
3. Os argumentos e os resultados são cortados aos oito mil caracteres. Um pedido enorme não faz explodir a tabela.

A consequência mais útil disto, para quem gere um volume razoável de encomendas, é a capacidade de responder à pergunta "esta encomenda foi criada por mim no painel ou pelo assistente?". Como o registo guarda o cliente, a ferramenta e o momento, essa reconstituição é possível depois do facto. Numa equipa onde várias pessoas mexem na mesma conta, isto vale bastante.

Um pormenor de engenharia que também interessa saber: a escrita no registo é feita da melhor forma possível mas não bloqueia nada. Se, por qualquer razão, a auditoria não conseguir ser gravada, a operação principal segue na mesma. Um registo é uma ferramenta de diagnóstico, não deve ser um ponto único de falha capaz de impedir uma encomenda legítima.

Como ver e terminar as ligações de assistentes

A quarta secção da página "Assistente IA" chama-se "Assistentes ligados" e é o inventário de tudo o que tem acesso à sua conta por esta via. Se ainda não ligou nada, mostra "Ainda não há nenhum assistente de IA ligado."

Cada linha da lista traz cinco informações e um botão:

Elemento da linha	O que indica
Nome do cliente	a aplicação que se registou e pediu acesso
Distintivo de permissão	"Acesso total" ou "Apenas leitura"
"Ligado"	a data em que a autorização foi concedida
"Última utilização"	a data da última chamada; mostra "Nunca" se nunca foi usada
"Terminar ligação"	corta o acesso daquele cliente

O campo "Última utilização" é o mais informativo dos cinco para efeitos de higiene. Uma ligação que diz "Nunca" semanas depois de ter sido criada é quase sempre uma tentativa de configuração que não chegou a funcionar, e não tem razão para continuar a existir. Uma ligação com utilização recente é a que está de facto a trabalhar.

Ao carregar em "Terminar ligação", aparece a pergunta de confirmação "Este assistente vai perder o acesso à sua conta. Continuar?". Se confirmar, o painel mostra "Ligação terminada." e a linha desaparece. Se alguma coisa correr mal, a mensagem é "Não foi possível terminar a ligação."

O efeito do corte é imediato e completo: o token de acesso e o de renovação daquele cliente deixam de valer, e a próxima chamada que ele fizer recebe um erro de autenticação. O cliente de IA, do lado dele, vai simplesmente deixar de conseguir usar as ferramentas do painel, e para voltar a ter acesso tem de recomeçar o processo de autorização desde o início, passando outra vez pelo ecrã de consentimento.

Há um caso que o botão não resolve, e convém não se enganar com isso: ligações feitas com chave de API não aparecem nesta lista. Uma chave não é uma autorização registada com nome e datas, é um segredo que o cliente envia em cada pedido. Para cortar uma ligação por chave, tem de regenerar a chave na página de chaves de API, o que invalida a anterior para todos os que a estiverem a usar, incluindo integrações suas que nada tenham a ver com IA.

Existe ainda a possibilidade de revogação a partir do próprio cliente, através do endpoint de revogação do OAuth, que alguns clientes chamam quando o utilizador remove o servidor da configuração. O efeito é o mesmo do botão, só muda quem inicia a operação.

Automação: fluxo de eventos e webhooks

Além de perguntar, o assistente pode acompanhar. As ferramentas de automação servem para saber o que mudou desde a última vez que olhou, sem ter de reler a lista de encomendas toda.

O painel gera oito tipos de evento, e os nomes não são traduzidos porque são identificadores técnicos:

Evento	Quando é gerado
order.created	uma encomenda foi criada
order.processing	a entrega começou
order.completed	a entrega ficou completa
order.partial	a entrega ficou incompleta
order.canceled	a encomenda foi cancelada
order.updated	houve outra alteração na encomenda
refill.created	foi pedida uma reposição
refill.updated	o estado de uma reposição mudou

A ferramenta list_events lê este fluxo com paginação por cursor: cada resposta traz um cursor que pode ser usado na chamada seguinte para continuar de onde parou. É o mecanismo certo para uma pergunta como "o que mudou nas minhas encomendas desde ontem", porque devolve exatamente as alterações e não o estado completo.

As outras três ferramentas gerem webhooks. Com list_webhooks vê os que existem, com create_webhook cria um novo e com delete_webhook apaga um. Um webhook é um endereço seu que o painel chama sempre que acontece um evento, com assinatura para poder verificar a origem. Duas notas de operação: o segredo de assinatura é mostrado uma única vez, no momento da criação, e apagar um webhook também descarta as entregas que estavam à espera de ser enviadas.

Há aqui uma escolha de arquitetura que vale a pena compreender, porque resolve um problema real. Nem toda a gente pode receber webhooks: quem está a desenvolver no computador local, quem não tem endereço fixo, quem não quer expor um serviço à internet. Para esses casos, list_events dá acesso à mesma informação por consulta, em vez de por notificação. Não é uma alternativa de segunda categoria: é o mesmo fluxo, lido de outra maneira.

A documentação completa de eventos, formato de carga útil e verificação de assinatura está na documentação da API, e aplica-se tal e qual, porque as ferramentas MCP são espelhos dos mesmos endpoints.

Comandos prontos: order_status, find_service e reorder

Além das ferramentas, o servidor publica três comandos prontos. Nos clientes de IA que os suportam, aparecem numa lista de atalhos e poupam-lhe a escrita da instrução completa.

Comando	O que faz	Argumentos
order_status	resume as encomendas recentes e assinala as que ficaram paradas ou incompletas	count, com 10 por omissão
find_service	compara 3 a 5 serviços para um pedido e apresenta os preços, sem criar nada	request, obrigatório, e quantity, opcional
reorder	repete uma encomenda anterior, pedindo confirmação antes	order_id, obrigatório

O order_status é o mais usado no dia a dia. Devolve, para cada encomenda, o número, o nome do serviço, o estado, a quantidade, o que falta entregar e o valor cobrado, e destaca separadamente as que não ficaram concluídas ou onde houve erro do fornecedor, sugerindo o que fazer em cada caso: esperar, cancelar ou pedir reposição.

O find_service é o que substitui a navegação no catálogo. Descreve o que quer, opcionalmente com a quantidade, e recebe uma tabela comparativa com preço, limites, indicação de reposição e tempo médio. A instrução deste comando é explícita num ponto: não cria encomendas. Apresenta as opções e o valor, e a decisão fica consigo.

O reorder é o mais delicado dos três e por isso é o mais cuidadoso. Lê a encomenda indicada, monta uma pré-visualização com o mesmo serviço, a mesma ligação e a mesma quantidade, mostra-lhe o valor atualizado e espera pela confirmação. Se não confirmar, não faz nada. E se detetar que ainda há uma encomenda a decorrer para a mesma ligação, avisa antes, porque encomendas repetidas para o mesmo endereço podem ser recusadas.

Quem não tiver um cliente que suporte estes atalhos não perde nada de essencial: pode obter o mesmo resultado escrevendo o pedido por palavras suas. Os comandos são conveniência, não capacidade.

A camada de transporte: o que o protocolo aceita e o que recusa

Esta secção interessa sobretudo a quem está a integrar ou a depurar uma ligação que não arranca. Se apenas quer usar o assistente, pode saltá-la sem perder nada.

O transporte é HTTP simples, com JSON-RPC 2.0, e é sem estado: não há identificador de sessão a manter entre pedidos, cada chamada traz consigo tudo o que precisa. Isto simplifica enormemente a operação, porque não há sessões a expirar nem a sincronizar.

Aspeto	Comportamento
Método HTTP	apenas POST; um GET devolve 405
Fluxo de eventos em tempo real	não existe; a mensagem de erro do 405 remete para POST
Versão de protocolo	2025-06-18 nativa; 2025-03-26 e 2024-11-05 também aceites
Pedidos em lote	suportados na forma de lista JSON-RPC
Pedido só com notificações	responde 202 sem corpo
Erro de ferramenta	não é erro de protocolo: vem como texto marcado como erro
Tamanho da resposta de uma ferramenta	cortada aos 100.000 caracteres

Os métodos suportados são initialize, tools/list, tools/call, prompts/list, prompts/get e ping, mais resources/list e resources/templates/list, que respondem com listas vazias por não haver recursos a expor neste servidor.

Vale a pena parar na linha do erro de ferramenta, porque é uma decisão de desenho com efeitos visíveis. Quando uma ferramenta falha, por exemplo porque o saldo não chega ou porque a quantidade está fora dos limites, a resposta não é um erro de protocolo que faça o cliente abortar: é uma resposta normal, com o texto do erro e uma marca a dizer que correu mal. Assim o modelo lê a explicação e pode corrigir-se, propondo outra quantidade ou outro serviço, em vez de simplesmente falhar sem saber porquê.

A negociação de versão acontece no arranque, no initialize. Um cliente mais antigo pede uma versão anterior e o servidor aceita, o que evita o cenário irritante de um cliente perfeitamente funcional recusar-se a ligar por causa de uma data.

Limites de pedidos: 600 por minuto por conta

O servidor MCP e a API v3 partilham o mesmo teto de pedidos, e essa partilha é intencional: o limite é da conta, não do caminho usado para lá chegar.

Limite	Valor	O que acontece ao ultrapassar
Por conta, por minuto	600 pedidos	resposta 429 com indicação de esperar 60 segundos
Por endereço de origem, por minuto	900 pedidos na camada da API v3	resposta 429

Na prática, uma conversa normal com um assistente nunca se aproxima destes números. Uma pergunta bem formulada gera meia dúzia de chamadas: uma pesquisa, uma ou duas fichas de serviço, uma pré-visualização e, se avançar, uma criação. Seiscentos pedidos por minuto é território de automação, não de conversa.

Os casos onde o limite aparece mesmo são dois. O primeiro é quando corre um lote grande, com muitas chamadas seguidas, ao mesmo tempo que outra integração sua já está a consumir o mesmo teto. O segundo é quando um cliente mal configurado entra em ciclo e repete a mesma chamada indefinidamente. Nos dois casos, a resposta 429 traz a indicação do tempo a esperar e os clientes de IA sérios respeitam-na.

Uma consequência que interessa a quem já tem integrações: ligar um assistente não lhe dá capacidade adicional. O teto é o mesmo que já tinha. Se está perto do limite com o seu código, o tráfego do assistente soma-se ao seu.

O que muda para revendedores e para painéis com marca própria

Quem revende com a sua própria marca tem aqui uma vantagem que é fácil de subestimar: o mecanismo inteiro funciona no domínio do revendedor, sem qualquer referência ao painel principal.

Os endereços anunciados nos documentos de descoberta são gerados a partir da origem do pedido. Quando um cliente do seu painel liga o assistente a partir do seu domínio, o emissor anunciado é o seu domínio, o ecrã de autorização é o seu ecrã, com o seu nome e as suas cores, e o endereço do servidor que o cliente guarda na configuração é o seu. O painel de origem não aparece em passo nenhum do processo.

Para o cliente final, isto significa que a experiência é idêntica à descrita neste texto: a mesma página "Assistente IA", os mesmos três passos, o mesmo ecrã de autorização, as mesmas dezoito ferramentas. O que muda são apenas os preços, que refletem a margem definida pelo revendedor, porque as ferramentas leem o catálogo tal como ele é apresentado naquele painel.

Do lado de quem revende, há três consequências operacionais que vale a pena antecipar:

1. É um argumento comercial que quase ninguém tem. Poder dizer a um cliente que ele pode gerir as encomendas a partir do assistente de IA que já usa é uma diferença real face a um painel que só oferece um formulário.
2. Não acrescenta trabalho de suporte técnico. Não há nada para instalar nem configurar do lado do revendedor: o mecanismo faz parte do painel e funciona no domínio assim que o painel está no ar.
3. Continua a valer o modelo económico habitual. Uma encomenda criada por IA é uma encomenda como as outras, com o mesmo custo base e a mesma margem.

Se está a montar ou a fazer crescer uma operação destas, o modelo comercial está descrito na página de painel com marca própria, a parte de posicionamento e preços no guia de revenda, e o percurso completo de quem começa do zero no artigo sobre como criar um negócio de revenda.

Uma nota final que evita um pedido de suporte previsível: uma conta criada num painel com marca própria só existe nesse painel. Se um cliente tentar ligar o assistente ao domínio principal com as credenciais do painel do revendedor, não vai conseguir, e a mensagem de erro não vai ser clara sobre a causa. O endereço a usar é sempre o do painel onde a conta foi criada.

Do lado do proprietário: o servidor de gestão

Esta secção existe por transparência e é deliberadamente curta. Quem apenas usa o painel como cliente pode saltá-la.

O painel expõe um segundo servidor MCP, em /api/mcp, destinado a quem administra a plataforma. Publica 57 ferramentas, distribuídas por áreas como visão geral e pesquisa, utilizadores, encomendas, pedidos de encomenda, serviços, categorias, fornecedores, pagamentos, pedidos de suporte, cupões e definições. A autenticação é feita com uma única chave secreta do servidor, aceite no cabeçalho de autorização, num cabeçalho próprio ou num parâmetro de consulta, sempre com comparação de tempo constante.

Se essa chave não estiver definida no ambiente, o endpoint está completamente fechado e responde com um erro de serviço indisponível. Não há modo degradado nem acesso parcial.

Do lado das proteções, três merecem menção porque são as que evitam estragos irreversíveis: o último administrador ativo não pode ser despromovido nem bloqueado, as operações que mexem em dinheiro são atómicas, com transação e bloqueio de linha, e todas as chamadas ficam no mesmo registo de auditoria descrito atrás.

A razão para mencionar isto num texto dirigido a clientes é simples: o painel é gerido pelo mesmo protocolo que lhe é oferecido, com as mesmas garantias de registo e as mesmas fronteiras. Não é uma funcionalidade experimental encostada de lado, é a forma como a plataforma trabalha.

MCP, API ou painel: o que usar em cada situação

Há três formas de fazer as mesmas coisas nesta plataforma, e escolher mal não parte nada, apenas dá mais trabalho do que o necessário.

Situação	Painel	MCP	API v3
Primeira encomenda, a aprender o funcionamento	melhor	possível	não
Comparar serviços antes de comprar	possível	melhor	possível
Verificar o estado de muitas encomendas	possível	melhor	possível
Criar encomendas todos os dias por processo automático	não	não recomendado	melhor
Integrar num site de revenda próprio	não	não	melhor
Carregar saldo	único caminho	não existe	não existe
Abrir um pedido de suporte	único caminho	não existe	não existe
Consultar preços dentro de uma conversa	possível	melhor	possível
Receber notificações de mudança de estado	não	por eventos	melhor, por webhook

A regra de bolso: o painel é para aprender e para tudo o que envolve dinheiro a entrar; o MCP é para o trabalho manual repetitivo que passa por perguntar, comparar e decidir; a API é para tudo o que corre sem ninguém a olhar. As três coexistem sem conflito, partilham a mesma conta e o mesmo saldo, e uma encomenda criada por qualquer uma delas aparece igual nas outras.

Para quem quer aprofundar cada caminho: o catálogo completo com preços e limites está em serviços, a referência técnica em documentação da API, a apresentação comercial da integração em API para painéis SMM e o manual de utilização do painel no guia como usar o Panel Follows.

Resolução de problemas: erros frequentes e o que significam

Esta tabela reúne os sintomas que aparecem mesmo, com a causa real e o que fazer a seguir.

Sintoma	Causa	O que fazer
Erro de token inválido, com código 401	o token de acesso passou as 8 horas de validade	o cliente renova-se sozinho com o token de renovação; se não o fizer, volte a ligar a partir do painel
405 ao abrir o endereço no navegador	tentou aceder por GET	o protocolo só aceita POST; o endereço não é para abrir no navegador
429	passou os 600 pedidos por minuto	espere o tempo indicado na resposta
"O pedido de ligação é inválido ou expirou. Comece de novo a partir do cliente."	o código de autorização passou os 10 minutos, ou o cliente não está registado	reinicie o processo a partir do cliente de IA
O pedido do token devolve erro 400	o cliente enviou PKCE no modo simples	só é aceite o método S256
O endereço de retorno é recusado	o endereço não corresponde ao que foi registado	a única flexibilidade é o número da porta em ligações locais
Erro de serviço indisponível no servidor de gestão	a chave secreta do servidor não está definida	diz respeito apenas ao proprietário do painel
A conta não é encontrada	contas criadas num painel com marca própria só valem nesse domínio	ligue-se a partir do domínio correto
O assistente diz que a ferramenta de criar encomendas não existe	a ligação foi autorizada como "Apenas leitura"	termine a ligação e volte a autorizar sem marcar a caixa
O assistente engana-se na ordem de grandeza do preço	leitura errada da unidade de preço	peça a pré-visualização; é ela que corresponde ao débito

Duas notas que resolvem a maioria dos casos que não estão na tabela. Primeira: quando alguma coisa não funciona logo na primeira ligação, o problema está quase sempre no endereço. Confirme que está a usar o do servidor de conta e não o de gestão, e que o domínio é o do painel onde a conta existe. Segunda: quando uma ligação que funcionava deixa de funcionar, a explicação mais provável é a validade do token ou uma revogação, e a solução é sempre a mesma, refazer a autorização a partir do cliente.

Se depois disto continuar sem funcionar, abra um pedido de suporte a partir do painel, indicando o cliente de IA que está a usar, o endereço que configurou e a mensagem exata que recebeu. A página de perguntas frequentes cobre as dúvidas gerais do painel que não são específicas desta funcionalidade.

Perguntas Frequentes

O que é o MCP, em poucas palavras?

O MCP, ou Model Context Protocol, é um protocolo aberto que define como um assistente de IA descobre e chama funções de um sistema externo. Num painel SMM, isso significa que o assistente pode consultar o catálogo, calcular preços, criar encomendas e acompanhar estados através de chamadas reais ao painel, em vez de responder com informação inventada. A comunicação faz-se em JSON-RPC 2.0 sobre HTTP e o conjunto de funções disponíveis chama-se lista de ferramentas.

Tenho de dar a palavra-passe do painel ao assistente?

Não, e em nenhum momento do processo isso é pedido. A autorização é feita no painel, num ecrã do painel, onde já tem sessão iniciada, e o que o cliente de IA recebe no fim é um token com prazo limitado, nunca as suas credenciais. A própria página da funcionalidade diz isso de forma explícita: a autorização é dada no painel e a palavra-passe nunca é partilhada com o cliente. Se alguma aplicação lhe pedir a palavra-passe do painel para ligar um assistente, não é este mecanismo que está a usar.

O assistente pode criar encomendas sem eu autorizar?

O servidor instrui o modelo a pedir confirmação explícita antes de criar qualquer encomenda, e a ferramenta que cria encomendas está marcada como destrutiva, o que leva os clientes de IA a pedirem confirmação por conta própria. Ainda assim, essa é uma proteção de comportamento e não uma barreira técnica. Se quiser uma garantia estrutural, autorize a ligação com a caixa "Dar acesso apenas de leitura (sem criar encomendas)" marcada: nesse caso as ferramentas de criação, cancelamento e reposição nem sequer são mostradas ao assistente.

Que clientes de IA são compatíveis?

Funciona com qualquer cliente que implemente MCP com OAuth 2.1, o que inclui os assistentes mais conhecidos e vários editores de código com suporte para servidores MCP. Para clientes que não implementam OAuth mas conseguem enviar cabeçalhos HTTP, existe o caminho alternativo da chave de API. A página da funcionalidade no painel traz exemplos prontos a copiar para configuração por comando e por ficheiro.

Como termino uma ligação e o que acontece depois?

Na página "Assistente IA", na lista "Assistentes ligados", carregue em "Terminar ligação" na linha do cliente que quer cortar e confirme a pergunta que aparece. A partir desse momento os tokens daquele cliente deixam de ser válidos e a próxima chamada que ele fizer é recusada. Para voltar a ligar, tem de recomeçar o processo a partir do cliente, passando outra vez pelo ecrã de autorização. Ligações feitas com chave de API não aparecem nesta lista e cortam-se regenerando a chave.

Quanto tempo dura o acesso? Tenho de voltar a ligar com frequência?

O token de acesso vale 8 horas, mas isso não significa que tenha de fazer nada de oito em oito horas. O cliente recebe também um token de renovação, válido 90 dias e renovado a cada utilização, que lhe permite obter um token de acesso novo sozinho. Na prática, uma ligação usada com regularidade mantém-se a funcionar sem intervenção sua. Se ficar meses sem usar, terá de autorizar de novo.

O assistente pode carregar saldo na minha conta?

Não. Não existe nenhuma ferramenta de pagamento, de carregamento ou de levantamento no conjunto entregue ao assistente, e por isso a operação é impossível, não apenas desaconselhada. O assistente pode avisá-lo de que o saldo não chega para a encomenda que está a considerar, porque consegue ler o saldo disponível, mas o carregamento é feito por si, no painel, pelos métodos habituais.

Devo ligar-me com OAuth ou com chave de API?

Se o seu cliente suporta OAuth, prefira OAuth: a autorização é dada no painel, aparece na lista de assistentes ligados com datas, pode ser limitada a apenas leitura e corta-se com um botão. A chave de API existe para clientes que não implementam OAuth mas conseguem enviar um cabeçalho, e tem duas desvantagens a pesar: fica guardada em texto no ficheiro de configuração e dá sempre acesso total, porque a limitação de permissões só existe no caminho OAuth.

Consigo ver no painel as encomendas criadas pelo assistente?

Sim. Uma encomenda criada por um assistente é uma encomenda normal em todos os aspetos: aparece na lista de encomendas, tem o mesmo estado, o mesmo progresso, os mesmos botões de reposição e cancelamento e o mesmo tratamento de reembolso. Além disso, cada chamada de ferramenta fica no registo de auditoria interno, com o cliente, a ferramenta e o momento, o que permite distinguir depois o que foi criado pelo assistente e o que foi criado à mão.

Os clientes de um painel com marca própria também podem ligar assistentes?

Sim, e fazem-no a partir do domínio desse painel, com o ecrã de autorização desse painel. Todos os endereços do processo são gerados a partir da origem do pedido, por isso o domínio do painel principal não aparece em passo nenhum. A única regra a respeitar é que a conta só existe no painel onde foi criada, portanto o endereço a configurar no cliente de IA tem de ser o desse painel.

O que acontece quando uma ferramenta devolve um erro?

O erro não interrompe a conversa. É devolvido como uma resposta normal, marcada como erro, com um código fixo e uma mensagem no idioma da conta, o que permite ao assistente ler a explicação e propor uma correção, por exemplo ajustar a quantidade ou escolher outro serviço. As instruções que o servidor entrega ao modelo são claras neste ponto: a mensagem deve ser transmitida tal como veio, sem inventar soluções.

Usar o MCP tem algum custo adicional?

Não há qualquer encargo extra associado a ligar um assistente: paga apenas as encomendas que criar, ao preço que estiver no catálogo no momento, exatamente como se as tivesse feito no painel. O que pode ter custo é o seu próprio cliente de IA, se for um serviço pago, mas isso é uma relação sua com esse fornecedor e não tem nada a ver com o painel.

Por onde começar

O caminho mais barato para perceber se isto lhe serve tem três passos e leva menos de meia hora. Abra a página "Assistente IA" em /dashboard/mcp, copie o "Endereço de ligação" e configure-o no cliente de IA que já usa, seguindo o exemplo correspondente. No ecrã de autorização, marque a caixa de apenas leitura. Depois faça três perguntas: quanto custa determinada quantidade de um serviço, quais são as opções com reposição para uma plataforma, e como estão as suas encomendas recentes.

Se as respostas lhe pouparem tempo, corte a ligação e volte a ligar com acesso total, e faça uma encomenda pequena num perfil que controla, para ver o fluxo completo de pré-visualização, confirmação e número de encomenda. Se não lhe pouparem, o painel continua exatamente onde estava, e não perdeu nada além do tempo de configuração.

Antes de escalar o uso, dois textos ajudam a evitar surpresas: o manual completo do painel, em como usar o Panel Follows, porque as regras de estados, reembolsos e reposição são as mesmas por qualquer via, e os termos de serviço, porque é lá que estão descritas as garantias que existem e, sobretudo, as que não existem. Se ainda não tem conta, o registo demora menos de um minuto.