Remote MCP-server i praktiken: en ny ingångspunkt för SaaS-produkter i AI-eran

SaaS-produkter har haft ett långvarigt problem: time-to-value är för långsam. Många användare lämnar innan de når det där "aha"-ögonblicket.

Vi har förbättrat Logtos onboarding många gånger. Det hjälpte, men flaskhalsen försvann inte. Du måste fortfarande läsa dokumentation, skumma igenom guider, installera SDK:er, koppla in konfigar, skriva kod, och sedan felsöka de sista 10% innan något fungerar.

Så vi testade en annan metod: en extern MCP-server som Logtos IDE-inbyggda kontrollplan. Istället för att klicka runt i ett administrationsgränssnitt konfigurerar du Logto och genererar integrationskod via en konversation, där du bygger appen.

En prompt kan ta dig från noll till en fungerande integration. Agenten genererar inte bara kod, den skapar och konfigurerar även Logto-applikationen i din tenant. Allt inifrån din IDE. (Prova Logto MCP Server)

I den här artikeln delar jag med mig av våra erfarenheter och tankar kring bygget av Logto MCP Server, inklusive:

• MCP vs. Agent Skills: varför vi valde MCP
• Problem vi stötte på vid lansering av en MCP-server, och hur vi löste dem
• Hur vi designar MCP-verktyg och hur du bör designa dina
• Våra förväntningar på MCP:s framtid

MCP vs. Agent Skills: varför vi valde MCP#

Innan vi bestämde hur AI skulle få tillgång till Logto utvärderade vi två alternativ: MCP-servrar och Agent Skills.

MCP-servrar finns i två former: lokala och externa.

En lokal MCP-server körs på användarens dator. Den kräver installation, miljöuppsättning, inloggningar och speciella autentiseringsflöden. I användning och leverans liknar den skills.

En extern MCP-server är hostad på serversidan. Användare ansluter via URL och auktoriserar via OAuth. Denna modell liknar mer en utökning av SaaS-tjänster.

Ur ett strukturellt perspektiv är en Agent Skill en kombination av "affärslogik + underliggande funktionalitet". Dessa funktioner kan vara verktyg, CLI:er eller API-anrop. MCP-verktyg kan bära detta lager på ett enhetligt sätt.

Så kärnfrågan är inte hur funktionalitet implementeras, utan hur den levereras till användarna.

• Agent Skills levererar: en komplett lokal verktygskedja (Skill-paket + lokal runtime + API-nycklar eller plattformsuppgifter + CLI-verktyg + installation, konfiguration, uppgradering och underhållsflöde).
  I grunden ger du användarna möjligheten att köra det själva.

• Externa MCP-servrar levererar: en extern tjänsteinmatning (URL + OAuth-inloggning).
  I grunden tillhandahåller du funktionaliteten som en tjänst.

Nedan jämför vi dem ur användarupplevelse, ekosystemräckvidd och leverans- och underhållskostnad.

Användarupplevelse#

Agent Skills är beroende av plattforms-API:er eller CLI:er. Användaren måste skapa API-nycklar eller installera och logga in på CLI först. Stegen är inte svåra, men höjer tröskeln.

MCP-servrar stödjer OAuth. Användaren loggar in med sitt SaaS-konto. Upplevelsen liknar "Logga in med Google".

För användarna är det enkelt att använda en MCP-server: skriv in en URL, logga in, anslut. Det är den upplevelsen vi vill ge.

Ekosystemräckvidd#

På MCP:s webbplats finns redan 104 AI-appar som stödjer MCP, inklusive verktyg som VS Code, Cursor och Windsurf.

Agent Skills är fortfarande plattformsspecifika. Även om plattformar börjar stödja dem, kan alla använda en MCP-server vi släpper direkt. När vi släpper en Skill, är det bara användarna på just den plattformen som kan använda den.

MCP ingår även i Agentic AI Foundation (AAIF). Det är en protokollstandard på ekosystemnivå. Ekosystemet kommer fortsätta växa. För oss gör detta MCP värd att investera långsiktigt i.

Leverans- och underhållskostnad#

Agent Skills är beroende av plattforms-API:er eller CLI:er, vilket snabbt kan leda till problem:

• Vad händer om API:et ändras?
• Vad händer om CLI-bryter kompatibilitet?
• Hur uppgraderar och distribuerar du Skill?

Du behöver även distribuera CLI:er, hantera utspridda credentials, anpassa till olika plattformar och guida användare i uppgraderingen. ROI är mycket låg.

MCP-servrar är mycket enklare. Användare ansluter till en URL. Den pekar alltid mot senaste versionen. När vi uppdaterar MCP-servern får användarna den nästa gång de ansluter. Ingen uppgradering behövs. Om API:er ändras uppdaterar vi dem i MCP-servern.

De flesta SaaS-produkter har redan stabil infrastruktur: robusta API:er och mogna autentiseringssystem. En MCP-server passar naturligt som "AI-gränssnitt" för API:et, precis som ett administrationsgränssnitt är ett annat gränssnitt ovanpå samma API:er.

För Logto passar MCP-servern vår arkitektur och utnyttjar våra styrkor.

Det centraliserar också alla förfrågningar till en ingångspunkt. Loggar och revisioner blir enklare. Behörigheter är tydliga: AI kan bara göra det användaren tillåter. Den här modellen är strukturellt renare för företags- och compliance-scenarier.

Problem vi stötte på vid lansering av en MCP-server, och hur vi löste dem#

MCP är inte perfekt. De flesta problemen handlar om ekosystemets mognad. De kommer förbättras över tid. Fram tills dess använder vi workarounds för att möta verkliga behov.

Fragmenterat stöd för MCP-funktioner#

MCP-specifikationen definierar många funktioner, men klientsidan stöd varierar:

• Verktyg: brett stöd
• OAuth: välstött i VS Code; verktyg som Cursor behöver mcp-remote som brygga
• Andra funktioner (Resurser, Prompter, Instruktioner): inkonsekvent stöd

Just nu är verktyg det pålitligaste gemensamma lagret (kolla MCP Community Page för att se vilka funktioner varje klient stödjer).

Vår strategi är enkel: bygg på verktyg.

LLM vet inte hur dina verktyg används#

Detta är ett affärslagersproblem.

Med Agent Skills paketeras affärslogik och kontext tillsammans. LLM vet hur de används. MCP levererar endast verktyg. Efter anslutning vet LLM inte:

• Användningsscenarierna
• Anropsordningen
• Affärsbegränsningarna

MCP har konceptet Instruktioner, men inte alla klienter stödjer det. Instruktioner läggs också till all kontext vid anslutning, vilket slösar tokens.

Ett annat förslag är att ha vägledning i verktygsbeskrivningarna. Men detta ger två problem:

• Beskrivningar blir komplexa. Flöden med flera verktyg ger snårig logik och svår hantering.
• När antalet verktyg växer konsumerar beskrivningarna stora delar av kontextfönstret.

Vår lösning: ett getInstructions-verktyg

Idén är enkel: om Instruktioner inte stöds ordentligt, gör dem till verktyg.

LLM kan anropa getInstructions vid behov.
För uppgift A anropar den getTaskAInstructions. MCP-servern returnerar en prompt som förklarar hur du slutför uppgiften A och hur du kombinerar andra verktyg.

Komplex affärslogik ligger bakom instruktion-verktygen. Andra verktyg förblir enkla. Verktygsbeskrivningarna fokuserar enbart på sina funktioner.

Det liknar Agent Skills: promtar laddas vid behov. Det är också effektivare än globala Instruktioner eftersom allt inte dumpas i kontexten.

LLM kan läcka dina hemligheter#

För många SaaS-produkter finns vissa hemligheter som aldrig får röjas (t.ex. client secrets, API-nycklar, eller webhook-signaturnycklar). Om de läcker kan andra utge sig för dig eller få direkt åtkomst till resurser.

Risken med LLM:er är att en chatt inte är en säker kanal. Konversationer kan loggas, kopieras, vidarebefordras eller hamna i felsökningsloggar. Du kan inte anta "bara jag och modellen kan se detta". Om du ger en långlivad hemlighet till en LLM, eller ber den skriva ut en hemlighet åt användaren, är det hög risk.

Detta är vanligt i traditionella webbapputvecklingar: utvecklare behöver ofta en hemlighet, lägger in den i serverns miljövariabler eller konfigfiler, och slutför sedan exempelvis SDK-initiering.

För att göra onboarding enkelt utan att kompromissa med säkerheten gör vi tre saker:

• Använd tillfälliga hemligheter vid integration

  Under den chattbaserade installationen returnerar MCP-servern bara kortlivade tillfälliga hemligheter (t.ex. giltiga i en timme). Det räcker för att integrationsflödet ska fungera, och de hinner oftast gå ut innan liveproduktion. Innan liveproduktion skapar och ersätter utvecklare dem med produktionshemligheter utanför chatten.

• Gör säkerhetsgränserna tydliga

  Vi varnar tydligt: skapa, klistra in eller spara aldrig produktionshemligheter i chatten. Vi påminner även utvecklare om att miljövariabler eller konfigfiler kan läcka om en agent/LLM får läsa dem via verktyg eller indirekt åtkomst. Sätt bara produktionshemligheter i miljöer där inga AI-assisterade integrationer används.

• Hantera inga produktionshemligheter i chatten; hänvisa till konsolen

  Långlivade hemligheter genereras eller delas aldrig i chatten. De skapas och hanteras på credentials-sidan i konsolen. I chatten ger vi endast en länk dit så användaren kan slutföra produktionsinställningen där.

Hur vi designar MCP-verktyg#

Vår väg#

Logto har ett fullt Management API. Vår första idé var enkel: exponera varje API-endpoint som ett MCP-verktyg.

Det misslyckades snabbt.

För det första: kontextexplosion. Logto har många API:er. Om man exponerar dem ett-till-ett fylls kontextfönstret. Varje verktygsbeskrivning kostar tokens.

För det andra: meningsbortfall. API:er är atomära byggstenar för utvecklare. Men användare av Logto MCP Server bygger inga system. De vill bara slutföra uppgifter. De bryr sig inte om hur många API:er som finns.

Exempel: Logto har ett sign-in-experience-API för varumärke, inloggningsmetoder, registreringsmetoder och säkerhetspolicys.
Först tänkte vi på hur vi skulle exponera samtliga parametrar för LLM. Hur vi kunde lära den att kombinera anropen.

Men det är fel tanke. Användarna anropar inget API. De vill ändra branding eller konfigurera inloggningsmetoder.

Därför ska verktygen vara updateBranding, updateSignInMethod, updateSignUpMethod. MCP-servern sköter API-sammansättningen internt.

Logto MCP Server ska ses som en produkt, inte en API-wrapper. Det är "ännu en admin-konsol".

Hur ska MCP-verktyg utformas?#

Regeln är tydlig:

• Om användarna använder din tjänst direkt (som en konsol) ska verktyg vara affärsorienterade.
• Om du erbjuder grundfunktionalitet för andra att bygga på, ska verktyg vara atomära och enkla. Exempel: en filsystem-MCP-server med read_file, write_file, så att kodagenter kan kombinera dem.

Ytterligare principer:

• Håll verktygslogik och beskrivningar enkla för att spara kontext.
• För komplexa arbetsflöden: använd getInstructions-verktyg för att ladda handledning vid behov. Håll deras beskrivningar enkla också.

Våra förväntningar på MCP:s framtid#

Under tiden vi byggde MCP-servern funderade vi också på vad som kan förbättra ekosystemet.

Leverans av funktionalitet på Skill-nivå#

Ibland måste MCP-servrar inte bara ge verktyg, utan även vägledning om hur de kombineras till färdiga uppgifter – precis som Agent Skills.

Detta är vanligt för SaaS. Exempel: GitHub MCP Server, Logto MCP Server eller analysplattformar. Användare vill ha arbetsflöden, inte atomära anrop.

getInstructions-verktyget är en tillfällig lösning. Protokollstöd vore bättre.

Sessionsbaserad MCP-aktivering#

Klienter ansluter till många MCP-servrar, men varje session behöver inte alla. Sessionsbaserad aktivering/inaktivering kan minska kontextspill.

Kontextisolering för MCP-verktygsanrop#

Verktygsanrop slukar mycket kontext. Om MCP-interaktioner hanteras av subagenter kan huvudkonversationen bara få kondenserade resultat.

Slutsats#

Detta är våra erfarenheter av att bygga en extern MCP-server.

Om du undersöker det här området, prova Logto MCP Server eller gå med i vår Discord för att prata implementation med andra i communityt.

Vi kommer även dela mer om arkitekturdesign och OAuth-flöden i framtida inlägg.