Agências sentem o custo das pequenas mudanças mais do que ninguém. Um cliente quer a barra de fim de ano no ar hoje, outro quer o widget da página de preços pausado durante um redesign, um terceiro quer os números do mês passado para um relatório. Num painel, isso são três logins e muitos cliques. Com o servidor MCP do Provedly, podem ser três frases no editor que você já tem aberto.
Este artigo mostra como configurar isso para que continue organizado à medida que a lista de clientes cresce. Para o caso das agências de forma mais ampla, incluindo como falar com os clientes sobre prova social honesta, veja prova social para agências.
Duas formas de estruturar as contas
O jeito de conectar depende de como estão organizadas as configurações do Provedly dos seus clientes.
Uma conta, vários sites. Se você gerencia uma carteira de clientes a partir de uma única conta do Provedly, cada cliente é um site nessa conta. Uma chave cobre todos, e o assistente vê todos os sites. É o mais simples de conectar, e significa que você precisa nomear as coisas com cuidado, porque "pause o widget da página inicial" é ambíguo quando doze sites têm um.
Uma conta por cliente. Se cada cliente tem sua própria conta do Provedly e deu acesso a você, cada conta precisa da sua própria chave. Dá mais trabalho de configurar e cria limites mais claros: uma chave do cliente A não consegue mexer no cliente B, e quando o contrato termina, o cliente revoga a sua chave e pronto.
Os limites do plano acompanham a conta. Na primeira configuração, os limites de sites, widgets e barras do seu plano são compartilhados entre todos os clientes. Na segunda, o plano de cada cliente vale para a conta dele.
Conectando várias contas
Os clientes MCP permitem adicionar mais de um servidor. Dê a cada um um nome que diga a qual cliente pertence:
claude mcp add --transport http provedly-northwind https://provedly.app/mcp \
--header "Authorization: Bearer provedly_NORTHWIND_KEY"
claude mcp add --transport http provedly-harbor https://provedly.app/mcp \
--header "Authorization: Bearer provedly_HARBOR_KEY"
O assistente passa a ver dois conjuntos das mesmas ferramentas, um por servidor, e você diz de qual cliente está falando. No Cursor, o equivalente são duas entradas no mcp.json, como mostra o guia do Cursor.
Mantenha essas configurações no escopo do usuário, não numa configuração de projeto que pode acabar commitada. Um repositório com as chaves de vários clientes é um dia ruim esperando para acontecer.
Nomes que sobrevivem a uma semana corrida
O assistente encontra widgets e barras pelo nome. Nomes genéricos causam confusão, então adote uma convenção e siga-a:
- Comece o nome das barras com a campanha e termine com o cliente ou site: "BF 2026 main sale, Northwind".
- Nomeie os widgets pela posição: "Product pages", "Pricing page", "Checkout".
- Nomeie as chaves pela pessoa e pelo cliente: "Maria, Harbor, read and write".
Os itens também podem ser referenciados pelo id (um UUID) ou pelo token, então, quando um nome for realmente ambíguo, peça ao assistente que liste os itens com seus ids e aja pelo id.
Um dia na prática
Uma manhã realista poderia ser assim.
Para a Northwind, crie uma barra de contagem regressiva chamada "Winter launch, Northwind" terminando em 1º de dezembro às 9h com a mensagem "A coleção de inverno abre em {timer}".
A barra é criada pausada. Mande ao cliente um print da prévia no painel, ou leia a mensagem para ele. Quando ele aprovar:
Para a Northwind, ative a barra do lançamento de inverno.
Depois:
Para a Harbor, pause o widget da página de preços. Eles estão refazendo a página esta semana.
E para os relatórios:
Para cada cliente, me dê impressões, cliques, pedidos verificados e pedidos assistidos por prova social com a receita de outubro.
O assistente chama get_stats uma vez por conta. Cole os números no seu relatório, com uma linha explicando o que significa "assistido por prova social"; medindo pedidos assistidos por prova social tem um texto que você pode aproveitar.
Níveis de acesso para uma agência
Nem todo mundo na equipe precisa alterar coisas. Uma divisão razoável:
| Função | Nível da chave |
|---|---|
| Gerente de conta, relatórios | Somente leitura |
| Gestor de campanhas | Leitura e escrita |
| Desenvolvedor, instalações | Somente leitura, mais o snippet |
| Backend enviando registros | Leitura e escrita, com chave própria |
Chaves somente leitura ainda podem chamar get_install_snippet, então um desenvolvedor que instala o script não precisa de acesso de escrita. O raciocínio por trás de cada nível está em chaves somente leitura vs. de escrita.
O que continua igual para os clientes
Às vezes os clientes temem que uma agência com ferramentas de IA possa inflar os números deles. Não pode. Registros adicionados pela API ou por um assistente levam o rótulo visível "Imported" no widget e nunca a marca Verified, e a página de verificação do cliente os lista em "Site owner's backend (API)". Só webhooks assinados da loja geram registros verificados. A página de verificação pública do cliente mostra as origens. Isso é algo bom de dizer em voz alta numa apresentação, e o limite da verificação explica em mais detalhes.
Perguntas frequentes
Uma chave pode acessar várias contas do Provedly?
Não. Uma chave pertence a uma conta. Conecte um servidor MCP por conta, cada um com sua própria chave e um nome claro.
O que acontece com as minhas chaves quando um cliente sai?
Se o cliente é dono da conta, ele revoga a sua chave em Settings e o acesso termina na hora. Se o site está na sua conta, resolva como combinado com o cliente e revogue qualquer chave que só existia para o trabalho dele.
Há custo extra por cliente?
Chaves, a API e o servidor MCP estão incluídos em todos os planos. O plano de cada conta define seus próprios limites.
Veja os limites de sites, widgets e barras de cada plano na página de preços.