Servidor MCP remoto em ação: um novo ponto de entrada para produtos SaaS na era da IA
Aprenda como construir um Servidor MCP Remoto para seu produto SaaS. Compartilhamos nossa experiência com MCP vs. Habilidades de Agente, integração com OAuth e design de ferramentas MCP.
YijunDeveloper
Pare de perder semanas com autenticação de usuários
Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.
Produtos SaaS têm um problema antigo: o tempo para gerar valor é muito lento. Muitos usuários desistem antes de chegar ao momento “aha”.
Já iteramos diversas vezes no onboarding do Logto. Isso ajudou, mas o gargalo não desapareceu. Você ainda acaba lendo documentação, pulando tutoriais, instalando SDKs, configurando arquivos, escrevendo código e depois depurando os últimos 10% antes de qualquer coisa funcionar.
Então tentamos uma abordagem diferente: um servidor MCP remoto como plano de controle nativo do IDE do Logto. Em vez de clicar em um console de administração, você configura o Logto e gera o código de integração através de uma conversa, no mesmo local em que está construindo o app.
Um único prompt pode te levar do zero até uma integração funcionando. O agente não apenas gera código, como também cria e configura o aplicativo Logto no seu tenant. Tudo de dentro do seu IDE. (Experimente o Logto MCP Server)
Neste artigo, vou compartilhar nossa experiência e pensamento ao construir o Logto MCP Server, incluindo:
MCP vs. Habilidades de Agente: por que escolhemos MCP
Problemas encontrados ao entregar um servidor MCP e como os resolvemos
Como projetamos ferramentas MCP, e como você deve projetar as suas
Nossas expectativas para o futuro do MCP
MCP vs. Habilidades de Agente: por que escolhemos MCP#
Antes de decidir como a IA deveria acessar o Logto, avaliamos duas opções: servidores MCP e Habilidades de Agente.
Servidores MCP têm duas formas: local e remoto.
Um servidor MCP local roda na máquina do usuário. Exige instalação de serviço, configuração de ambiente, credenciais, ou fluxos de login especiais. Na experiência e entrega, é muito parecido com habilidades.
Um servidor MCP remoto é hospedado no lado do servidor. Usuários conectam por URL e autorizam via OAuth. Esse modelo se aproxima de uma extensão remota de um serviço SaaS.
De forma estrutural, uma Habilidade de Agente é uma combinação de "lógica de negócio + capacidades subjacentes". Essas capacidades podem ser ferramentas, CLIs ou chamadas de API. Ferramentas MCP podem carregar essa camada de maneira unificada.
Então, a questão-chave não é como as capacidades são implementadas, mas como são entregues aos usuários.
Habilidades de Agente entregam: uma cadeia de ferramentas local (pacote de Habilidade + runtime local + chaves API ou credenciais de plataforma + ferramentas CLI + fluxo de instalação, configuração, atualização e manutenção).
Em essência, você entrega a capacidade para o usuário rodar por conta própria.
Servidores MCP remotos entregam: uma entrada de serviço remoto (URL + login OAuth).
Em essência, você oferece a capacidade como serviço.
Abaixo, comparamos ambos por experiência do usuário, alcance no ecossistema e custo de entrega e manutenção.
Habilidades de Agente normalmente dependem de APIs de plataforma ou CLIs. O usuário precisa primeiro criar chaves de API ou instalar e fazer login em CLIs. Esses passos não são complexos, mas aumentam a barreira de entrada.
Servidores MCP suportam OAuth. O usuário faz login com sua conta SaaS. A experiência se parece com “Entrar com Google”.
Para o usuário, usar um servidor MCP é simples: informar uma URL, fazer login, conectar. Esta é a experiência que queremos entregar.
No site do MCP, já existem 104 apps de IA que suportam MCP, incluindo ferramentas como VS Code, Cursor e Windsurf.
Habilidades de Agente ainda são específicas de plataforma. Mesmo que muitas plataformas comecem a suportá-las, quando lançamos um servidor MCP, qualquer usuário pode usá-lo imediatamente. Ao lançarmos uma Habilidade, apenas usuários daquela plataforma conseguem utilizá-la.
MCP também faz parte da Agentic AI Foundation (AAIF). É um padrão no nível de protocolo. O ecossistema vai continuar crescendo. Para nós, isso faz o MCP valer o investimento de longo prazo.
Habilidades de Agente dependem de APIs de plataforma ou CLIs, e isso logo traz problemas:
E se a API mudar?
E se a CLI perder compatibilidade?
Como atualizar e redistribuir a Habilidade?
Você também precisa distribuir CLIs, gerenciar credenciais espalhadas, adaptar à múltiplas plataformas e guiar o usuário na atualização. O ROI é muito baixo.
Servidores MCP são bem mais simples. O usuário conecta a uma URL. Ela sempre aponta para a versão mais recente. Quando atualizamos o servidor MCP, os usuários recebem na próxima conexão. Não é preciso atualizar nada. Se as APIs mudam, atualizamos no servidor MCP.
A maioria dos produtos SaaS já tem infraestrutura robusta: boas APIs e sistemas de autenticação maduros. Um servidor MCP se encaixa naturalmente como "interface IA" da API, da mesma forma que um console de administração é outra interface sobre as mesmas APIs.
Para o Logto, optar por um servidor MCP encaixou na nossa arquitetura e aproveitou nossos pontos fortes.
Além disso, centraliza todos os pedidos em um só ponto de entrada. Logs e auditorias ficam simples. Permissões são claras: IA só faz o que o usuário autoriza. Esse modelo é estruturalmente mais limpo, especialmente para empresas e cenários com compliance.
Problemas encontrados ao entregar um servidor MCP e como os resolvemos#
O MCP não é perfeito. A maioria dos problemas está ligada à maturidade do ecossistema. Eles vão melhorar ao longo do tempo. Até lá, usamos alguns contornos para suprir necessidades reais.
Com Habilidades de Agente, lógica de negócio e contexto vêm juntos. O LLM sabe usar aquilo. MCP apenas fornece ferramentas. Após a conexão, o LLM não conhece:
Os cenários de uso
A ordem das chamadas
As restrições de negócio
MCP prevê o conceito de Instruções, mas nem todos clientes suportam. Instruções também jogam todo o conteúdo no contexto assim que conecta, o que desperdiça tokens.
Outra ideia é colocar o guia nas descrições das ferramentas. Mas isso causa dois problemas:
As descrições ficam complexas. Fluxos com múltiplas ferramentas criam lógica emaranhada e difícil de manter.
Conforme o número de ferramentas cresce, as descrições consomem boa parte da janela de contexto.
Nosso contorno: forneça uma ferramenta getInstructions
A ideia é simples: se Instruções não são bem suportadas, transforme isso em ferramentas.
O LLM pode chamar getInstructions conforme precisar.
Para a tarefa A, chama getTaskAInstructions. O servidor MCP retorna um prompt explicando como completar a tarefa A e como combinar outras ferramentas.
A lógica de negócio complexa fica escondida atrás das ferramentas de instrução. As demais ferramentas permanecem simples. As descrições se concentram apenas em sua função.
Isso é parecido com Habilidades de Agente: prompts sob demanda. É mais eficiente do que Instruções globais, pois evita jogar tudo no contexto.
Para muitos produtos SaaS, alguns segredos não podem ser expostos (por exemplo, client secrets, chaves de API ou segredos de webhook). Se vazarem, outros podem te imitar ou obter acesso direto a recursos.
O risco nos LLMs é que um chat não é um canal seguro. Conversas podem ser salvas, copiadas, encaminhadas ou parar em logs de debug. Você não pode assumir que “apenas eu e o modelo podemos ver isso”. Então entregar um segredo com longa validade ao LLM, ou pedir que ele gere um segredo para o usuário copiar, é muito arriscado.
Isso é comum em integrações web tradicionais: desenvolvedores precisam do segredo, colocam em variáveis de ambiente do servidor ou arquivos de configuração, e finalizam passos como inicializar SDKs.
Para facilitar o onboarding sem comprometer a segurança dos segredos, fazemos três ações:
Usar segredos temporários durante a integração
Durante a configuração via chat, o servidor MCP só retorna segredos temporários de curta duração (por exemplo, válidos por 1 hora). Eles bastam para testar a integração, e normalmente expiram antes de ir para produção. Antes de ir para produção, o desenvolvedor cria e substitui tudo por segredos válidos de verdade, fora do chat.
Deixar a fronteira de segurança explícita
Avisamos claramente: não crie, cole ou armazene segredos de produção no chat. Lembramos também que até variáveis de ambiente podem vazar se um agente / LLM conseguir ler via ferramentas ou acesso indireto. Coloque segredos de produção apenas em ambientes sem integração assistida por IA.
Não manipular segredos de produção no chat; oriente o usuário para o console
Segredos de longa duração não são gerados nem distribuídos via chat. São criados e administrados na página de credenciais do console. No chat, apenas damos um link direto para o console, para o usuário concluir todo o processo lá.
O Logto tem uma API de gerenciamento completa. Nossa primeira ideia foi simples: expor cada endpoint da API como uma ferramenta MCP.
Isso falhou rápido.
Primeiro, explosão de contexto. O Logto tem muitas APIs. O mapeamento 1 a 1 preenche toda a janela de contexto. Cada descrição de ferramenta custa tokens.
Segundo, perda de significado. APIs são blocos atômicos para desenvolvedores. Mas os usuários do Logto MCP Server não estão construindo sistemas. Eles só querem finalizar tarefas. Não ligam para quantas APIs existem.
Exemplo: O Logto tem uma API sign-in-experience para customização visual, métodos de login, métodos de cadastro e políticas de segurança.
No início, pensamos em como expor todos os parâmetros ao LLM. Como ensinar a combinar as chamadas?
Mas esse é o pensamento errado. Usuários não querem chamar APIs. Eles querem trocar o branding ou configurar métodos de login.
Logo, as ferramentas devem ser updateBranding, updateSignInMethod, updateSignUpMethod. O servidor MCP compõe as APIs internamente.
O Logto MCP Server deve ser tratado como um produto, não apenas um wrapper de API. É "outro console de administração".
Se os usuários interagem diretamente com seu serviço (como em um console), as ferramentas devem ser orientadas ao negócio.
Se você fornece capacidades básicas para outros construírem em cima, ferramentas devem ser atômicas e simples. Exemplo: um servidor MCP de filesystem com read_file, write_file, e assim agentes de código combinam as funções.
Princípios adicionais:
Mantenha a lógica e a descrição simples para economizar contexto.
Para fluxos complexos, use ferramentas getInstructions para carregar a orientação sob demanda. Deixe as descrições delas simples também.
Às vezes, servidores MCP precisam fornecer não só ferramentas, mas também diretrizes para combiná-las em tarefas, como nas Habilidades de Agente.
Isso é comum em SaaS. Por exemplo, GitHub MCP Server, Logto MCP Server ou plataformas de analytics. Usuários querem fluxos de trabalho, não chamadas atômicas.
A ferramenta getInstructions é um contorno. O ideal seria suporte no nível do protocolo.
Clientes conectam a muitos servidores MCP, mas nem toda sessão precisa de todos. Habilitar/desabilitar recursos por sessão pode reduzir o desperdício de contexto.
Isolamento de contexto nas chamadas de ferramentas MCP#
Chamadas de ferramentas MCP consomem bastante contexto. Se as interações MCP forem tratadas por sub-agentes, a conversa principal poderia receber só resultados resumidos.
Essa é nossa experiência construindo um servidor MCP remoto.
Se você está explorando esse caminho, experimente o Logto MCP Server ou entre no nosso Discord para trocar experiências reais de implementação com a comunidade.
Vamos compartilhar detalhes de planejamento de arquitetura e fluxos OAuth em posts futuros.
