Se a tua agência quer oferecer um servidor MCP aos clientes, o padrão que funciona é um servidor por cliente, construído a partir do site e dos documentos desse cliente, publicado no domínio do próprio cliente. No SuperCognit isto não exige código: importas o site do cliente — é rastreado para uma base de conhecimento com citações em cerca de dois minutos —, carregas os documentos que o site não cobre, associas as ferramentas que quiseres, publicas. Cada servidor vive no seu próprio workspace, isolado de todos os outros clientes que geres.
Uma única construção produz duas superfícies. O cliente recebe um agente de chat que pode pôr no site e um servidor MCP que a equipa ou os clientes dele podem adicionar ao Claude ou a qualquer outro cliente MCP. O mesmo conhecimento, a mesma configuração, a responder nos dois sítios — o que significa que o entregável que mostras na primeira reunião e o entregável a que a equipa deles se liga são o mesmo objeto.
Porquê um por cliente, e não um servidor com pastas de clientes
O atalho tentador é um único servidor da agência com uma secção por cliente. Resiste. As regras de preços de dois clientes a partilhar uma base de conhecimento acabam por se encontrar numa mesma resposta — e esse é um telefonema que não queres atender.
- O isolamento é estrutural. Um workspace é uma fronteira rígida; um servidor só responde com o que o seu próprio workspace contém. Não é prompt engineering que faz a separação.
- A autenticação é por servidor. Cada servidor implementa OAuth 2.1 segundo a especificação atual — validação de issuer, registo CIMD —, por isso quem se pode ligar decide-se cliente a cliente, não ao nível da agência.
- A saída é limpa. Se um cliente sair, entregas ou desativas um workspace. Nenhum outro cliente dá por isso.
- A marca também se separa. Há suporte para domínios personalizados, por isso cada servidor responde no hostname do próprio cliente, não no teu.
O que entra no servidor de um cliente
Três tipos de material, na mistura que o negócio do cliente precisar:
- O rastreio do site. Importado e citado, para que cada resposta aponte para a página de onde veio — o que importa quando é a própria equipa do cliente a verificar o trabalho da máquina.
- Documentos. As coisas que o site nunca diz: tabelas de preços, políticas, o guia de onboarding, as FAQ que vivem na pasta de enviados de alguém.
- Ferramentas. As ferramentas HTTP que configuras tornam-se ferramentas MCP invocáveis, para que o servidor possa verificar disponibilidade ou consultar uma encomenda em vez de apenas descrever como se faria.
Depois, uma decisão por cliente: privado ou público. Um hotel boutique pode publicar um servidor público, para que o assistente de um hóspede pergunte por quartos e tarifas. Um gabinete de contabilidade com 40 pessoas quer provavelmente um privado — um cérebro interno de procedimentos e políticas a que só a equipa se pode ligar. A construção é a mesma nos dois casos; muda o público, muda a fronteira.
A questão da avença
Um entregável de agência que se degrada é um passivo, e a maioria dos entregáveis de IA degrada-se depressa. Este mantém-se sozinho: o conhecimento ressincroniza com uma cadência definida, até de hora a hora, por isso quando o cliente atualiza o site, o servidor acompanha sem precisar de um ticket. É isso que transforma o trabalho de um projeto num serviço produtizado que podes descrever com honestidade numa proposta.
Quanto ao dinheiro, dois caminhos. Ou integras o servidor na avença que já faturas, ou vendes o acesso diretamente por lugar: subscrições Stripe, faturas e pagamentos vêm incluídos, com o SuperCognit como merchant of record a cobrar uma comissão de plataforma. Em qualquer dos casos, não estás a construir infraestrutura de faturação nem a andar atrás de faturas.
O primeiro cliente, numa tarde
Escolhe o cliente cujo site é o produto
Hotéis, clínicas, empresas com páginas de serviços profundas — negócios cujo site já responde a perguntas são as vitórias mais rápidas. O Four Seasons Fairways, cliente do SuperCognit, tem exatamente esse perfil: um empreendimento cujos hóspedes fazem as mesmas perguntas a época inteira.
Importa e lê
Rastreia o site e depois lê de facto o que a base de conhecimento contém. As lacunas que encontrares são os documentos a pedir no e-mail de arranque — os clientes respondem mais depressa a uma lista concreta do que a um pedido genérico de conteúdo.
Publica as duas superfícies
O agente de chat dá ao cliente algo para ver na primeira reunião; o servidor MCP é a parte que a equipa dele liga ao Claude. Põe-no no domínio deles antes da demo de entrega, não depois.
Define a cadência de sincronização e afasta-te
Frequente para páginas que mudam — tarifas, disponibilidade, menus —, mais lenta para o resto. Assim, a linha de manutenção da tua proposta é verdadeira sem ser cara.
Os planos são em euros, com um período de teste de 7 dias — tempo suficiente para construíres o servidor do primeiro cliente antes de o apresentares, que é a demo que fecha o negócio.