Servidor MCP remoto em ação: um novo ponto de entrada para produtos SaaS na era da IA

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
• As nossas expectativas para o futuro do MCP

MCP vs. Skills de Agente: porque escolhemos MCP#

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.

Experiência de utilizador#

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.

Alcance do ecossistema#

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.

Custo de entrega e manutenção#

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.

Suporte fragmentado de funcionalidades MCP#

A especificação MCP define muitas funcionalidades, mas o suporte dos clientes é variado:

• Ferramentas: amplamente suportadas
• OAuth: bem suportado no VS Code; ferramentas como o Cursor precisam de mcp-remote como ponte
• Outras funcionalidades (Recursos, Prompts, Instruções): suporte inconsistente

Neste momento, ferramentas são a camada comum mais fiável (confere a Página da Comunidade MCP para veres que funcionalidades cada cliente suporta).

Por isso a nossa estratégia é simples: construir em cima das ferramentas.

O LLM não sabe como utilizar as tuas ferramentas#

Este é um problema de camada de negócio.

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.

O LLM pode vazar os teus segredos#

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.

Como desenhamos ferramentas MCP#

O nosso caminho#

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".

Como desenhar ferramentas MCP#

A regra fica clara:

• 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.

As nossas expectativas para o futuro do MCP#

Ao construir o servidor MCP, também pensámos em como o ecossistema poderia melhorar.

Entrega de capacidades ao nível de Skill#

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.

Ativação MCP ao nível da sessão#

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.

Conclusão#

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.