Remote MCP-server in actie: een nieuw toegangspunt voor SaaS-producten in het AI-tijdperk

SaaS-producten hebben een oud probleem: de tijd tot waarde is te traag. Veel gebruikers haken af voordat ze het “aha”-moment bereiken.

We hebben het onboardingproces van Logto meerdere keren aangepast. Dit hielp enigszins, maar het knelpunt bleef bestaan. Je moet nog steeds documentatie lezen, tutorials doorspitten, SDK’s installeren, configuraties aansluiten, code schrijven en vervolgens de laatste 10% debuggen voordat er iets werkt.

Dus probeerden we een andere aanpak: een remote MCP-server als Logto’s IDE-native control plane. In plaats van klikken door een beheerdersconsole configureer je Logto en genereer je integratiecode via een gesprek, precies daar waar je de app bouwt.

Eén prompt kan je van nul naar een werkende integratie brengen. De agent genereert niet alleen code; deze maakt en configureert ook de Logto-applicatie in jouw tenant. Alles binnen je IDE. (Probeer Logto MCP Server)

In dit artikel deel ik onze ervaringen en inzichten over het bouwen van de Logto MCP Server, waaronder:

• MCP vs. Agent Skills: waarom we voor MCP kozen
• Problemen die we tegenkwamen bij het uitrollen van een MCP-server en hoe we die oplosten
• Hoe we MCP-tools ontwerpen, en hoe jij die het beste kunt ontwerpen
• Onze verwachtingen voor de toekomst van MCP

MCP vs. Agent Skills: waarom we voor MCP kozen#

Voordat we besloten hoe AI toegang moest krijgen tot Logto, hebben we twee opties geëvalueerd: MCP-servers en Agent Skills.

MCP-servers zijn er in twee vormen: lokaal en remote.

Een lokale MCP-server draait op de machine van de gebruiker. Dit vereist installatie van een service, configuratie van de omgeving, inloggegevens of speciale inlogflows. Qua gebruik en distributie lijkt dit sterk op Agent Skills.

Een remote MCP-server wordt aan de serverzijde gehost. Gebruikers verbinden via een URL en autoriseren via OAuth. Dit model lijkt meer op het uitbreiden van een SaaS-dienst.

Vanuit een structuurperspectief is een Agent Skill een combinatie van "businesslogica + onderliggende mogelijkheden". Die mogelijkheden kunnen tools, CLI’s of API-calls zijn. MCP-tools kunnen deze laag op een uniforme manier aanbieden.

De hoofdvraag is dus niet hoe de functies zijn geïmplementeerd, maar hoe ze bij de gebruiker terecht komen.

• Agent Skills leveren: een volledige lokale toolchain (Skill-pakket + lokale runtime + API-sleutels of platform-credentials + CLI-tools + installatie, configuratie, upgrades en onderhoud).
  In wezen geef je de gebruiker de mogelijkheid om zelfstandig te draaien.

• Remote MCP-servers leveren: een remote service-entry (URL + OAuth-login).
  In wezen bied je de functionaliteit als een service aan.

Hieronder vergelijken we ze op gebruikerservaring, reikwijdte van het ecosysteem en kosten van levering en onderhoud.

Gebruikerservaring#

Agent Skills zijn meestal afhankelijk van platform-API’s of CLI’s. Gebruikers moeten eerst API-sleutels maken of CLI’s installeren en inloggen. Deze stappen zijn niet moeilijk, maar maken de drempel hoger.

MCP-servers ondersteunen OAuth. Gebruikers loggen in met hun SaaS-account. De ervaring is vergelijkbaar met “Inloggen met Google.”

Voor de gebruiker is een MCP-server eenvoudig: voer een URL in, log in, maak verbinding. Dit is de ervaring die we willen leveren.

Reikwijdte van het ecosysteem#

Op de MCP-website zijn er al 104 AI-apps die MCP ondersteunen, waaronder tools als VS Code, Cursor en Windsurf.

Agent Skills zijn nog steeds platformspecifiek. Zelfs als veel platforms ze gaan ondersteunen, kan de gebruiker bij de uitrol van een MCP-server er direct gebruik van maken. Lever je een Skill, dan kunnen alleen gebruikers van dat platform er gebruik van maken.

MCP wordt ook ondersteund door de Agentic AI Foundation (AAIF). Het is een protocolstandaard. Het ecosysteem zal blijven groeien. Voor ons betekent dit dat MCP een langetermijninvestering waard is.

Levering en onderhoudskosten#

Agent Skills zijn afhankelijk van platform-API’s of CLI’s, wat snel problemen veroorzaakt:

• Wat als de API verandert?
• Wat als de CLI niet meer compatibel is?
• Hoe upgrade en verspreid je de Skill?

Je moet ook CLI’s distribueren, verspreide credentials beheren, meerdere platforms ondersteunen en gebruikers begeleiden bij upgrades. Het rendement is erg laag.

MCP-servers zijn veel eenvoudiger. Gebruikers verbinden met een URL. Die wijst altijd naar de nieuwste versie. Wanneer wij de MCP-server updaten, zien gebruikers de update direct bij de volgende verbinding. Geen upgrades nodig. Als API’s veranderen, passen wij ze aan binnen de MCP-server.

De meeste SaaS-producten beschikken al over sterke infrastructuur: solide API’s en volwassen auth-systemen. Een MCP-server past hier natuurlijk als het "AI-interface" van de API, net zoals een adminconsole een andere interface is bovenop dezelfde API’s.

Voor Logto past een MCP-server bij onze architectuur en benut het onze sterke punten.

Alle verzoeken worden ook gecentraliseerd in één toegangspunt. Logboeken en audits zijn eenvoudiger. Rechten zijn duidelijk: AI kan alleen doen wat de gebruiker toestaat. Dit model is structureel overzichtelijker voor enterprise- en compliance-scenario’s.

Problemen die we tegenkwamen bij het uitrollen van een MCP-server, en hoe we die oplosten#

MCP is niet perfect. De meeste issues zijn problemen rondom de volwassenheid van het ecosysteem. Deze zullen met de tijd verbeteren. Tot dat moment gebruiken wij workarounds voor de echte behoeften.

Gefragmenteerde ondersteuning voor MCP-functies#

De MCP-specificatie beschrijft veel functies, maar de ondersteuning door clients verschilt:

• Tools: breed ondersteund
• OAuth: goed ondersteund in VS Code; tools als Cursor hebben mcp-remote als brug nodig
• Andere functies (Resources, Prompts, Instructions): wisselende ondersteuning

Op dit moment zijn tools de meest betrouwbare gemeenschappelijke laag (kijk op de MCP Community Page om te zien welke features elke client ondersteunt).

Onze strategie is dus simpel: bouw op tools.

LLM weet niet hoe het jouw tools moet gebruiken#

Dit is een probleem op het business-niveau.

Bij Agent Skills zijn businesslogica en context samen verpakt. De LLM weet hoe deze te gebruiken. MCP levert alleen tools. Na het verbinden weet de LLM niet:

• De gebruiksscenario’s
• De aanroepvolgorde
• De zakelijke beperkingen

MCP kent het concept Instructions, maar niet alle clients ondersteunen dit. Instructions stoppen ook alle inhoud gelijk in de context bij het verbinden, wat veel tokens kost.

Een ander idee is om richtlijnen in toolbeschrijvingen te plaatsen. Maar dit leidt tot twee problemen:

• Beschrijvingen worden complex. Multi-tool-workflows creëren verstrengelde logica en zijn moeilijk te onderhouden.
• Naarmate het aantal tools groeit, kost dit een groot deel van het contextvenster.

Onze workaround: een getInstructions-tool aanbieden

Het idee is eenvoudig: als Instructions niet goed ondersteund worden, maak er tools van.

De LLM kan getInstructions oproepen wanneer nodig.
Voor taak A roept het getTaskAInstructions aan. De MCP-server retourneert een prompt die uitlegt hoe taak A afgerond moet worden en hoe andere tools te combineren.

Complexe businesslogica blijft achter de instructietools. Andere tools blijven eenvoudig. Beschrijvingen van tools focussen alleen op hun eigen functie.

Dit lijkt op Agent Skills: prompts worden on demand geladen. Het is ook efficiënter dan globale Instructions, omdat alles dumpen in de context wordt voorkomen.

LLM kan je geheimen lekken#

Voor veel SaaS-producten zijn bepaalde geheimen die nooit mogen worden blootgegeven (bijvoorbeeld clientsleutels, API-sleutels of webhook signing keys). Als deze lekken, kunnen anderen zich voordoen als jou of direct toegang krijgen tot resources.

Het risico bij LLM’s is dat een chat geen veilig kanaal is. Gesprekken kunnen worden gelogd, gekopieerd, doorgestuurd of in debuglogs terechtkomen. Je kunt er niet van uitgaan dat “alleen jij en het model dit zien.” Dus langlevende geheimen aan een LLM geven of vragen deze uit te laten voeren zodat gebruikers ze kunnen kopiëren, is risicovol.

Dit is gebruikelijk bij traditionele webappintegraties: ontwikkelaars hebben vaak een geheim nodig, stoppen het in server-omgevingsvariabelen of configuraties en ronden dan stappen zoals het initialiseren van SDK’s af.

Om onboarding makkelijk te houden zonder geheimen onveilig te maken, doen wij drie dingen:

• Gebruik tijdelijke geheimen tijdens de integratie

  Tijdens de op chat gebaseerde setup geeft de MCP-server alleen tijdelijke geheimen terug (bijvoorbeeld geldig voor 1 uur). Dit is voldoende om de integratie werkend te krijgen, en vaak verlopen ze nog voordat je live gaat. Vóór livegang maken ontwikkelaars buiten de chat een langlevend geheim aan en vervangen deze.

• Maak de beveiligingsgrens expliciet

  We waarschuwen gebruikers duidelijk: maak, plak of bewaar nooit productiegeheimen in de chat. We herinneren ontwikkelaars er ook aan dat zelfs omgevingsvariabelen of configuratiebestanden kunnen lekken als een agent of LLM ze via tools of indirecte toegang kan lezen. Zet productiegeheimen alleen in omgevingen waar geen AI-integratie wordt gebruikt.

• Geen productiegeheimen via chat verwerken; leid gebruikers naar de console

  Langlevende geheimen worden niet via de chat gegenereerd of verspreid. Ze worden aangemaakt en beheerd op de credentials-pagina van de console. In de chat geven we alleen een directe link naar de console, zodat gebruikers daar de productiegeheimen kunnen instellen.

Hoe wij MCP-tools ontwerpen#

Onze weg#

Logto heeft een volledige Management API. Ons eerste idee was simpel: elke API-endpoint als een MCP-tool aanbieden.

Dit faalde snel.

Ten eerste: context-explosie. Logto heeft veel API’s. Ze één op één mappen vult het contextvenster. Elke toolbeschrijving kost tokens.

Ten tweede: betekenisverlies. API’s zijn bouwstenen voor ontwikkelaars. Maar gebruikers van de Logto MCP Server bouwen geen systemen. Ze willen gewoon taken afronden en geven niet om het aantal beschikbare API’s.

Voorbeeld: Logto heeft een sign-in-experience-API voor branding, inlogmethoden, aanmeldmethoden en beveiligingsbeleid.
Aanvankelijk dachten we na over alle parameters blootstellen aan de LLM. Hoe leer je het om calls te combineren?

Maar dit is de verkeerde mindset. Gebruikers roepen geen API’s aan. Ze willen branding aanpassen of inlogmethoden configureren.

Dus tools moeten zijn updateBranding, updateSignInMethod, updateSignUpMethod. De MCP-server handelt de API-compositie intern af.

Logto MCP Server moet worden gezien als een product, niet als een API-wrapper. Het is “een andere adminconsole.”

Hoe je MCP-tools ontwerpt#

De regel wordt duidelijk:

• Als gebruikers jouw service direct gebruiken (zoals een console), moeten tools businessgericht zijn.
• Bied je basisfuncties aan om op te bouwen, houd tools dan atomair en eenvoudig. Bijvoorbeeld: een filesystem MCP-server met read_file, write_file, daarna laten coding agents de combinaties maken.

Aanvullende principes:

• Houd toolinglogica en -beschrijvingen eenvoudig om context te besparen.
• Voor complexe workflows: gebruik getInstructions-tools om on-demand richtlijnen te laden. Houd die beschrijvingen ook eenvoudig.

Onze verwachtingen voor de toekomst van MCP#

Tijdens het bouwen van de MCP-server dachten we ook na over wat het ecosysteem kan verbeteren.

Skill-level capaciteitslevering#

Soms moeten MCP-servers niet alleen tools aanbieden, maar ook richtlijnen om deze te combineren tot taken, zoals bij Agent Skills.

Dit komt vaak voor in SaaS. Bijvoorbeeld GitHub MCP Server, Logto MCP Server of analytics-platformen. Gebruikers willen workflows, geen losse calls.

De getInstructions-tool is een workaround. Ondersteuning op protocolniveau zou beter zijn.

Sessie-niveau MCP-in/uitschakeling#

Clients verbinden met meerdere MCP-servers, maar niet elke sessie heeft ze allemaal nodig. Sessie-niveau aan/uit-schakelen zou contextverspilling verminderen.

Contextisolatie voor MCP-toolaanroepen#

Toolaanroepen nemen veel context in. Als MCP-interacties door sub-agents worden afgehandeld, kan het hoofdgesprek alleen het samengevatte resultaat ontvangen.

Conclusie#

Dit zijn onze ervaringen met het bouwen van een remote MCP-server.

Als je deze richting wilt verkennen, probeer dan de Logto MCP Server of sluit je aan bij onze Discord om echte implementatie-ervaringen te delen met de community.

We zullen ook architectuurontwerp en details over de OAuth-flow in toekomstige artikelen delen.