Servidor MCP remoto em ação: um novo ponto de entrada para produtos SaaS na era da IA
Aprende como construir um Servidor MCP Remoto para o teu produto SaaS. Partilhamos a nossa experiência com MCP vs Skills de Agente, integração OAuth e design de ferramentas MCP.
YijunDeveloper
Pare de perder semanas com autenticação de utilizadores
Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.
Os produtos SaaS têm um problema antigo: o tempo para obter valor é demasiado lento. Muitos utilizadores desistem antes de chegarem ao momento “aha”.
Já melhorámos o onboarding do Logto várias vezes. Ajudou, mas o estrangulamento não desapareceu. Continuas a acabar por ler documentação, passar por tutoriais, instalar SDKs, configurar ficheiros, escrever código e depois depurar os últimos 10% até tudo funcionar.
Por isso experimentámos outra abordagem: um servidor MCP remoto como o plano de controlo nativo no IDE do Logto. Em vez de navegares num painel de administração, configuras o Logto e geras código de integração através de uma conversa, mesmo onde estás a construir a app.
Um só prompt pode levar-te do zero a uma integração funcional. O agente não só gera código, como também cria e configura a aplicação Logto no teu tenant. Tudo dentro do teu IDE. (Experimenta o Logto MCP Server)
Neste artigo, partilho a nossa experiência e pensamento em torno da construção do Logto MCP Server, incluindo:
MCP vs. Skills de Agente: porque escolhemos MCP
Problemas que encontrámos ao lançar um servidor MCP, e como os resolvemos
Como desenhamos ferramentas MCP, e como deves desenhar as tuas
Antes de decidirmos como a IA deve aceder ao Logto, avaliámos duas opções: servidores MCP e Skills de Agente.
Os servidores MCP têm duas formas: local e remoto.
Um servidor MCP local corre na máquina do utilizador. Requer instalação do serviço, configuração do ambiente, credenciais ou fluxos de login especiais. Na utilização e entrega, é muito semelhante a skills.
Um servidor MCP remoto está alojado no lado do servidor. Os utilizadores ligam-se por URL e autorizam com OAuth. Este modelo é mais próximo da extensão de serviços SaaS.
Do ponto de vista estrutural, uma Skill de Agente é uma combinação de "lógica de negócio + capacidades subjacentes". Essas capacidades podem ser ferramentas, CLIs ou chamadas API. As ferramentas MCP conseguem transportar esta camada de forma unificada.
Por isso, a questão-chave não é como as capacidades são implementadas, mas como são entregues aos utilizadores.
Skills de Agente entregam: uma cadeia completa de ferramentas locais (pacote Skill + runtime local + chaves API ou credenciais de plataforma + ferramentas CLI + fluxos de instalação, configuração, atualização e manutenção).
No essencial, dás a capacidade ao utilizador de correr tudo por si próprio.
Servidores MCP remotos entregam: um ponto de entrada de serviço remoto (URL + login OAuth).
Em essência, forneces a capacidade como serviço.
Abaixo comparamos a experiência de utilizador, o alcance no ecossistema, e custos de entrega e manutenção.
As Skills de Agente normalmente dependem de APIs de plataforma ou CLIs. Os utilizadores devem criar chaves API ou instalar e iniciar sessão nos CLIs primeiro. Estes passos não são complexos, mas aumentam a barreira de entrada.
Os servidores MCP suportam OAuth. Os utilizadores fazem login com a conta SaaS. A experiência é tipo “Iniciar sessão com o Google.”
Para os utilizadores, usar um servidor MCP é simples: introduzir um URL, iniciar sessão, ligar. É esta a experiência que queremos entregar.
No site oficial MCP, já existem 104 apps de IA que suportam MCP, incluindo ferramentas como o VS Code, Cursor e Windsurf.
As Skills de Agente ainda são específicas a cada plataforma. Mesmo que muitas plataformas comecem a suportá-las, quando lançamos um servidor MCP, os utilizadores podem usá-lo imediatamente. Quando lançamos uma Skill, só os utilizadores dessa plataforma a podem usar.
O MCP também está incluído na Agentic AI Foundation (AAIF). É um padrão ao nível do protocolo. O ecossistema vai continuar a crescer. Para nós, isto faz do MCP um investimento a longo prazo válido.
As Skills de Agente dependem de APIs de plataforma ou CLIs, o que rapidamente traz problemas:
E se a API mudar?
E se o CLI quebrar compatibilidade?
Como se faz a atualização e redistribuição da Skill?
Também tens de distribuir CLIs, gerir credenciais dispersas, adaptar a várias plataformas, e guiar utilizadores na atualização. O ROI é muito baixo.
Servidores MCP são muito mais simples. Os utilizadores ligam-se a um URL. Aponta sempre para a versão mais recente. Quando atualizarmos o servidor MCP, os utilizadores obtêm-no da próxima vez que se ligam. Não são necessárias atualizações. Se as APIs mudarem, atualizamos dentro do próprio servidor MCP.
A maioria dos produtos SaaS já tem uma infraestrutura sólida: boas APIs e sistemas de autenticação maduros. Um servidor MCP encaixa-se naturalmente como "interface de IA" da API, tal como o painel de administração é outra interface sobre as mesmas APIs.
Para o Logto, escolher um servidor MCP encaixa na nossa arquitetura e explora os nossos pontos fortes.
Também centraliza todos os pedidos num só ponto de entrada. Os logs e auditorias ficam mais fáceis. As permissões são claras: a IA só pode fazer o que o utilizador autorizar. Este modelo é estruturalmente mais limpo para cenários empresariais e de compliance.
Problemas que encontrámos ao lançar um servidor MCP, e como os resolvemos#
O MCP não é perfeito. A maioria dos problemas está na maturidade do ecossistema. Eles vão melhorar com o tempo. Antes disso, usamos soluções de recurso para responder às necessidades reais.
Com Skills de Agente, a lógica de negócio e o contexto vêm juntas. O LLM sabe como usá-las. O MCP só fornece ferramentas. Depois de se ligar, o LLM não sabe:
Os cenários de utilização
A ordem das chamadas
As restrições de negócio
O MCP tem o conceito de Instruções, mas nem todos os clientes o suportam. As Instruções também colocam todo o conteúdo no contexto na altura da ligação, desperdiçando tokens.
Outra ideia é pôr orientações nas descrições das ferramentas. Mas isso causa dois problemas:
As descrições tornam-se complexas. Fluxos com muitas ferramentas criam lógica embaraçada e difícil de manter.
Com o aumento do número de ferramentas, as descrições consomem grande parte da janela de contexto.
A nossa solução: fornecer uma ferramenta getInstructions
A ideia é simples: se as Instruções não são bem suportadas, transforma-as em ferramentas.
O LLM pode chamar getInstructions quando precisa.
Para a tarefa A, chama getTaskAInstructions. O servidor MCP devolve o prompt com a explicação de como completar a tarefa A e como combinar outras ferramentas.
A lógica de negócio complexa fica escondida nas ferramentas de instrução. As outras ferramentas ficam simples. As descrições das ferramentas focam-se só na sua função.
Isto é semelhante ao conceito de Skills de Agente: os prompts carregam-se quando necessário. É também mais eficiente do que Instruções globais porque evita o carregamento de tudo no contexto.
Para muitos produtos SaaS, certos segredos nunca podem ser divulgados (por exemplo, client secrets, chaves API ou chaves de assinatura de webhook). Se vazarem, outros podem fazer-se passar por ti ou aceder diretamente a recursos.
O risco com LLMs é que um chat não é canal seguro. As conversas podem ser registadas, copiadas, reenviadas ou aparecer em logs de depuração. Não podes assumir que “só eu e o modelo vemos isto.” Assim, entregar um segredo de longa duração a um LLM, ou pedir-lhe para mostrar um segredo ao utilizador, é de alto risco.
Isto é comum nas integrações web tradicionais: os developers muitas vezes precisam de um segredo, colocam-no em variáveis de ambiente no servidor ou ficheiros de configuração, e só depois finalizam passos, como inicializar SDKs.
Para manter o onboarding simples sem comprometer a segurança dos segredos, fazemos três coisas:
Usar segredos temporários durante a integração
Durante a configuração via chat, o servidor MCP só devolve segredos temporários e de curta duração (por exemplo, válidos por 1 hora). Chegam para a integração funcionar, e normalmente expiram antes de ires para produção. Antes do lançamento, os developers criam e substituem por segredos de produção fora do chat.
Tornar o limite de segurança explícito
Avisamos claramente os utilizadores: não criar, colar ou guardar segredos de produção no chat. Também relembramos os developers de que mesmo variáveis de ambiente ou ficheiros de configuração podem vazar, se um agente / LLM as ler por ferramentas ou acesso indireto. Só meter segredos de produção em ambientes onde não é usada integração assistida por IA.
Não tratar segredos de produção no chat; encaminhar os utilizadores para o painel de administração
Segredos de longa duração não são gerados ou distribuídos pelo chat. São criados e geridos na página de credenciais do painel. No chat, só fornecemos um link direto para o painel para que os utilizadores finalizem lá a configuração dos segredos de produção.
O Logto tem uma Management API completa. A primeira ideia foi simples: expor cada endpoint da API como ferramenta MCP.
Isto falhou rapidamente.
Primeiro, explosão de contexto. O Logto tem muitas APIs. Associações um a um enchem a janela de contexto. Cada descrição de ferramenta custa tokens.
Segundo, perda de significado. As APIs são blocos atómicos para developers. Mas os utilizadores do Logto MCP Server não estão a construir sistemas. Só querem concluir tarefas. Não lhes interessa quantas APIs existem.
Exemplo: o Logto tem uma API sign-in-experience para branding, métodos de login, métodos de registo e políticas de segurança.
Ao princípio pensámos em como expor todos os parâmetros ao LLM. Como ensiná-lo a combinar chamadas.
Mas este é o mindset errado. Os utilizadores não querem chamar APIs. Querem mudar a imagem ou configurar métodos de login.
Portanto, as ferramentas deviam ser updateBranding, updateSignInMethod, updateSignUpMethod. O servidor MCP compõe as APIs internamente.
O Logto MCP Server deve ser tratado como produto, não um wrapper de API. É "outro painel de administração".
Se os utilizadores usam diretamente o teu serviço (tipo um painel), as ferramentas devem ser orientadas ao negócio.
Se forneces capacidades base para outros construírem, as ferramentas devem ser atómicas e simples. Exemplo: um servidor MCP para filesystem com read_file, write_file, depois agentes de código combinam-nas.
Princípios adicionais:
Manter a lógica e descrições das ferramentas simples para poupar contexto.
Para fluxos de trabalho complexos, usa ferramentas getInstructions para carregar orientações quando necessário. Mantém as suas descrições simples também.
Por vezes, os servidores MCP precisam de fornecer não só ferramentas, mas também orientação sobre como combiná-las em tarefas, como as Skills de Agente.
Isto é comum em SaaS. Por exemplo, GitHub MCP Server, Logto MCP Server ou plataformas analíticas. Os utilizadores querem fluxos de trabalho, não chamadas atómicas.
A ferramenta getInstructions é uma solução de recurso. Suporte ao nível do protocolo seria melhor.
Os clientes ligam-se a vários servidores MCP, mas nem todas as sessões precisam de todos. Ativar/desativar ao nível de sessão pode reduzir o desperdício de contexto.
Isolamento de contexto nas chamadas de ferramentas MCP#
As chamadas de ferramentas consomem muito contexto. Se as interações MCP forem tratadas por subagentes, a conversa principal só recebe os resultados condensados.
Esta é a nossa experiência a construir um servidor MCP remoto.
Se estás a explorar este caminho, experimenta o Logto MCP Server ou junta-te ao nosso Discord para trocar experiências reais de implementação com a comunidade.
Vamos também partilhar detalhes de design de arquitetura e fluxo OAuth em futuros posts.
