O que é um servidor MCP? Guia para fundadores de SaaS saberem se precisam de um

O que é um servidor MCP?

Um servidor MCP é um serviço que descreve o que o seu produto faz num formato que os assistentes de IA entendem, para que um cliente logado possa pedir ao Claude, ao ChatGPT ou ao GitHub Copilot que trabalhe com os próprios dados dele no seu produto. Ele fala o Model Context Protocol (MCP), um padrão aberto para conectar aplicações de IA a ferramentas e dados externos. A sua API continua fazendo o trabalho; o servidor fica na frente, faz o login das pessoas e informa ao assistente quais ações existem.

Num produto de help desk, isso significa que um cliente pode pedir ao assistente que já paga para resumir os tickets escalados da semana, e a resposta vem do seu produto, com as permissões desse cliente.

A Anthropic apresentou o MCP em novembro de 2024 e, em dezembro de 2025, o doou à Agentic AI Foundation, um fundo da Linux Foundation cofundado com a Block e a OpenAI. Em outubro de 2026, a revisão vigente é a 2026-07-28, a quinta revisão datada do protocolo. Este guia cobre a decisão que vem antes de construir; o nosso serviço de desenvolvimento de servidores MCP cobre a construção.

Como uma requisição percorre um servidor MCP

Há três partes: o host é a aplicação de IA que o seu cliente usa, um client dentro dela mantém uma conexão com um servidor, e o servidor é o seu. Por design, um servidor não lê a conversa inteira nem enxerga dentro de outros servidores: você recebe as chamadas de tools e seus argumentos, não o chat ao redor.

Do lado do cliente:

1. Ele adiciona o seu servidor ao assistente, por URL ou a partir de um diretório, e faz login com a conta dele no seu produto.
2. O assistente pede ao seu servidor as tools e lê o nome e a descrição de cada uma.
3. Ele faz uma pergunta, e o modelo escolhe uma tool e seus argumentos.
4. Dependendo do client e da tool, o assistente pede que ele confirme a chamada.
5. O seu servidor verifica o token e a permissão daquela tool, chama a sua API e devolve um resultado curto.
6. O modelo escreve a resposta ou chama outra tool.

O passo 3 surpreende a maioria dos times de produto: o modelo escolhe as tools pelos nomes e descrições, então esse texto é copy de produto lido por um modelo. Revise-o como o texto da interface e teste com requisições reais.

Tools, resources e prompts

Um servidor MCP pode oferecer três tipos de coisa, e a especificação os separa por quem decide quando são usados:

Comece pelas tools: são o que os clientes percebem, e o suporte a resources e prompts varia conforme o client.

Onde os clientes usariam e como o encontrariam

Os assistentes que os seus clientes já usam se conectam a servidores MCP remotos, hospedados na internet em vez de instalados por cada usuário; o anúncio da fundação pela Anthropic cita ChatGPT, Cursor, Gemini, Microsoft Copilot e Visual Studio Code entre os produtos que oferecem suporte ao MCP. Conforme a documentação de outubro de 2026, eles diferem na forma como um cliente adiciona o seu servidor e no que uma listagem pública exige de você:

Duas regras de revisão moldam o próprio produto. Os critérios de revisão de conectores da Anthropic rejeitam uma tool genérica que lê e escreve ao mesmo tempo, como uma tool api_request com um parâmetro method, e o diretório do Claude não aceita conectores que movimentam dinheiro. Os requisitos de revisão da OpenAI pedem que as tools devolvam apenas o que a requisição estritamente precisa. Se o seu produto movimenta dinheiro, planeje um servidor ao qual os clientes se conectem por URL, com uma confirmação antes de cada pagamento.

Os seus clientes realmente querem um?

Um servidor ao qual ninguém se conecta é manutenção sem retorno, então verifique antes:

• Conte os pedidos. Pesquise 90 dias de tickets de suporte, anotações de vendas e threads da comunidade por ChatGPT, Claude, Copilot, Cursor e MCP. Um pedido que cita uma tarefa, como "o Claude consegue ler os nossos tickets?", diz mais do que um que cita o protocolo.
• Busque o nome do seu produto no registry. O MCP Registry lista servidores públicos sob namespaces que os publicadores verificaram. Em 14 de outubro de 2026, uma busca por Zendesk retornou seis servidores e por HubSpot sete, nenhum sob um namespace controlado por alguma das duas empresas; Stripe retornou quinze, incluindo o com.stripe/mcp da própria Stripe. O registry não é completo, então a ausência de uma entrada não prova nada, mas servidores de terceiros para a sua API são demanda visível, e alguns clientes talvez já estejam entregando as API keys deles a um servidor pelo qual você não pode responder.
• Confira a sua categoria nos diretórios. Se os concorrentes estão listados no diretório do Claude ou do ChatGPT e você não, espere que isso apareça nas reuniões de vendas.

Depois faça o teste real mais barato: um servidor somente leitura com três ou quatro tools, oferecido a alguns design partners. Durante um mês, observe quantos o conectam e quantos voltam depois da primeira tentativa. Se ninguém voltar, você descobriu isso antes de construir escritas, listagens e suporte.

Para que os assistentes de IA recomendem a sua empresa, um servidor não ajuda: nenhum assistente documenta que encontre sozinho as tools de um site, como registram as nossas notas sobre sites prontos para agentes, e o nosso guia para aparecer nas respostas de IA cobre o que ajuda. Para IA que executa um processo dentro da sua própria empresa, veja a automação com IA.

O que expor primeiro

Escolha de três a cinco tarefas que os seus clientes já fazem no produto e que entregariam a um assistente, e dê a cada uma a sua própria tool, com leituras antes de escritas. Para um produto hipotético de help desk:

Três regras fazem a tabela funcionar:

• Retorne menos do que a sua API retorna. Threads completas, notas internas e todos os campos personalizados enchem o contexto do modelo com dados de que a pergunta não precisava. Retorne resumos e IDs; deixe o get_ticket buscar o resto.
• Rotule cada tool com honestidade. As tool annotations dizem aos clients se uma tool apenas lê ou pode destruir algo. Pelos padrões do protocolo, uma tool sem rótulo é presumida destrutiva, e os critérios de revisão do Claude dizem que tools somente leitura podem rodar sem perguntar a cada vez, enquanto as destrutivas sempre pedem confirmação. Rótulos corretos significam menos interrupções nas leituras.
• Faça do rascunho a escrita padrão. Um rascunho que o cliente aprova no seu produto dá ao assistente um trabalho útil sem lhe dar a última palavra.

O login é uma decisão de produto

Com OAuth, cada pessoa faz login com a própria conta e o assistente recebe apenas o que ela aprova. As regras de autorização do MCP resolvem a mecânica; as perguntas de produto são suas:

• A qual workspace uma conexão dá acesso. Muitos usuários de SaaS pertencem a vários. Decida se uma conexão cobre um workspace ou todos, e diga qual na tela de consentimento.
• Como os scopes se chamam. Um administrador pode aprovar tickets:read e drafts:write; um pedido de acesso total é recusado. As boas práticas de segurança do MCP listam scopes curinga e anunciar todos os scopes possíveis entre os erros comuns.
• Como um administrador vê e revoga. Liste os assistentes conectados nas configurações, ao lado das API keys, com a data do último uso e um botão de revogar.
• Como os times compartilham. Nos planos Team e Enterprise do Claude, um proprietário adiciona o conector e cada membro se conecta com a própria conta; uma credencial compartilhada dá a cada membro o acesso dela. Chaves compartilhadas servem para ferramentas internas, não para dados de clientes.

Os riscos de segurança que vêm junto

O modelo que chama as suas tools pode ser convencido a fazer coisas. A OWASP coloca a injeção de prompt em primeiro lugar entre os riscos de aplicações com LLM, inclusive a indireta, em que as instruções chegam dentro do conteúdo que o modelo lê: um ticket de suporte, um documento compartilhado, uma página da web. Os dados dos seus próprios clientes podem carregá-la. A página de ajuda sobre conectores personalizados da Anthropic também alerta que servidores maliciosos podem esconder instruções e que o modo Research do Claude pode chamar tools de um conector sem aprovação adicional.

A lethal trifecta, de Simon Willison, é o teste mais útil que conhecemos: dados privados, conteúdo não confiável e uma forma de enviar dados para fora. Um assistente com as três coisas pode ser manipulado a vazar dados, e ele argumenta que nenhuma barreira impede isso de forma confiável. Um servidor de help desk tem as duas primeiras por natureza, já que os tickets são privados e escritos por pessoas de fora. Então pergunte, a cada tool de escrita, se ela acrescenta a terceira: o send_reply poderia enviar por e-mail os dados de um cliente para um endereço plantado em outro ticket?

Três perguntas para cada tool antes de ela ir ao ar:

1. Algum texto que ela retorna pode ter sido escrito por alguém que não seja o usuário logado?
2. Ela pode enviar dados para fora da conta ou buscar um endereço que recebe?
3. Se um modelo manipulado a chamasse com os piores argumentos válidos, o que poderia acontecer dentro da permissão dela?

Onde tools que respondem sim às duas primeiras possam se encontrar numa mesma conversa, separe os scopes delas, exija confirmação ou elimine uma. Duas regras da especificação do MCP não são opcionais: aceite apenas tokens emitidos para o seu servidor e nunca repasse o token de um cliente a outra API. O julgamento do modelo nunca é o seu controle de acesso.

Quanto custa construir e manter

O servidor em si raramente é o maior custo; a estimativa cresce com tudo o que envolve a confiança:

• Uma API que não está pronta: faltam endpoints, não há permissões por usuário nem limites de taxa. Sem isso, o primeiro projeto é o desenvolvimento de aplicativos web.
• OAuth, se o seu produto ainda não tem login com telas de consentimento e scopes.
• Cada tool de escrita, com o scope, a confirmação e o registro de auditoria dela.
• Cada client e diretório que você prometer, com contas de teste, atualizações da política de privacidade e rodadas de revisão.
• Visualizações interativas dentro do chat (MCP Apps), se o texto não bastar.

Depois, a manutenção. Cinco revisões datadas em menos de dois anos mostram que o protocolo se move; a mais recente eliminou o handshake inicial em que os servidores anteriores se apoiam. Os recursos obsoletos normalmente permanecem pelo menos doze meses antes de serem removidos, o que torna as atualizações planejáveis, não opcionais. Trate o servidor como qualquer API pública, com política de versões, monitoramento e um responsável com nome. A nossa página de preços explica como orçamos esse trabalho.

O que aprendemos operando o nosso CMS com MCP

O CMS por trás do dardo.studio, o EmDash, tem um servidor MCP integrado que aceita OAuth ou tokens de acesso pessoal. Os nossos agentes trabalham por ele: criam rascunhos de artigos, enviam imagens, ligam cada artigo aos seus serviços e releem cada rascunho antes de qualquer coisa ir ao ar. Este artigo chegou ao CMS assim. Quatro coisas que levaríamos para um servidor voltado a clientes:

• Uma lista longa de tools serve aos seus próprios agentes, não aos seus clientes. Um servidor interno pode expor dezenas de tools; para clientes, lance um conjunto pequeno, porque opções quase idênticas tornam a escolha do modelo menos confiável.
• Rotule cada tool. Tools sem indicação de somente leitura ou destrutiva são tratadas como possivelmente destrutivas, o que é seguro mas gera mais confirmações, e as revisões de diretório pedem uma indicação em cada uma.
• Espere diferenças de versão. Servidores e clients migram para novas revisões do protocolo em ritmos diferentes; teste com as revisões que os clients dos seus clientes realmente usam.
• Peça o mínimo de scopes por padrão. Uma página de consentimento que deixa a pessoa desmarcar scopes funciona para um time pequeno; um produto com milhares de clientes deveria pedir menos de início.

Duas lições vieram do uso. A importação de Markdown do CMS achata as tabelas em linhas de texto simples, então os nossos agentes enviam as tabelas no formato estruturado e conferem o resultado com uma tool de leitura: dê aos seus agentes um jeito de verificar o próprio trabalho. E as regras que importam moram no servidor: o CMS se recusa a publicar um artigo sem resumo, sem imagem de capa com texto alternativo e sem texto alternativo em cada imagem, não importa o que se tenha dito a um agente. O nosso servidor público no dardo.studio, com duas tools somente leitura e sem login, está descrito nas nossas notas sobre sites prontos para agentes.

Você deveria construir um agora?

Construa agora um servidor pequeno, somente leitura, se os clientes pedem para usar o seu produto a partir de um assistente, a sua API já aplica permissões por usuário e o registry ou os diretórios confirmam a demanda. Se a sua API não está pronta ou ninguém pediu, arrume primeiro a API e faça o teste com design partners quando alguém pedir.

Quando estiver pronto, o nosso serviço de desenvolvimento de servidores MCP parte da sua API e das tarefas que os seus clientes pedem. Envie-nos as duas e diremos se já vale a pena construir um servidor.