Etä-MCP-palvelin toiminnassa: uusi sisäänkäynti SaaS-tuotteille tekoälyn aikakaudella

SaaS-tuotteilla on pitkäaikainen ongelma: aika arvon saavuttamiseen on liian hidas. Monet käyttäjät lopettavat ennen kuin he pääsevät “aha”-hetkeen asti.

Olemme kehittäneet Logton sisäänrakennusta monta kertaa. Se auttoi, mutta pullonkaula ei poistunut. Edelleen lopulta luet dokumentaatiota, selaat tutoriaaleja, asennat SDK:ta, konfiguroit asetuksia, kirjoitat koodia ja lopulta debuggaat viimeiset 10 %, ennen kuin mikään toimii.

Joten kokeilimme toista lähestymistapaa: etä-MCP-palvelinta Logton IDE-syntyisenä hallintatasontana. Sen sijaan, että klikkaisit hallintakonsolia, konfiguroit Logton ja generoit integraatiokoodin keskustelun muodossa, suoraan siellä missä rakennat sovellusta.

Yksi kehotus voi viedä sinut nollasta toimivaan integraatioon. Agentti ei ainoastaan generoi koodia, vaan se myös luo ja konfiguroi Logto-sovelluksen vuokralaisellesi. Kaikki suoraan IDE:stäsi käsin. (Kokeile Logto MCP -palvelinta)

Tässä artikkelissa jaan kokemuksemme ja ajatteluamme Logto MCP -palvelimen rakentamisesta, mukaan lukien:

• MCP vs. Agent Skills: miksi valitsimme MCP:n
• Ongelmat, joihin törmäsimme toimittaessamme MCP-palvelinta, ja miten ratkoimme ne
• Miten suunnittelemme MCP-työkaluja ja miten sinun kannattaisi omasi suunnitella
• Odotuksemme MCP:n tulevaisuudelle

MCP vs. Agent Skills: miksi valitsimme MCP:n#

Ennen päätöstä siitä, miten tekoälyn pitäisi päästä käsiksi Logtoon, arvioimme kahta vaihtoehtoa: MCP-palvelimet ja Agent Skills.

MCP-palvelimilla on kaksi muotoa: paikallinen ja etä.

Paikallinen MCP-palvelin ajetaan käyttäjän koneella. Se vaatii palvelun asennusta, ympäristön asetusta, tunnistetietoja tai erityisiä kirjautumisprosesseja. Käytössä ja toimituksessa se on hyvin samankaltainen kuin Skillit.

Etä-MCP-palvelin on palvelinpuolella ylläpidetty. Käyttäjät yhdistävät URL:iin ja valtuuttavat OAuthilla. Tämä malli muistuttaa enemmän SaaS-palvelun laajennusta.

Rakenteen näkökulmasta, Agent Skill on yhdistelmä "liiketoimintalogiikka + taustalla olevat kyvykkyydet". Nämä kyvykkyydet voivat olla työkaluja, CLI-ohjelmia tai API-kutsuja. MCP-työkalut voivat yhdistää tämän kerroksen yhtenäisesti.

Joten oleellinen kysymys ei ole, miten kyvykkyydet toteutetaan, vaan miten ne toimitetaan käyttäjille.

• Agent Skills toimittaa: täyden paikallisen työkaluketjun (Skill-paketti + paikallinen ajonaikainen ympäristö + API-avaimet tai alustatunnisteet + CLI-työkalut + asennus, konfigurointi, päivitys ja ylläpitoprosessi).
  Perimmiltään annat käyttäjille mahdollisuuden ajaa kyvykkyyttä itse.

• Etä-MCP-palvelin toimittaa: etäpalvelun sisäänkäynnin (URL + OAuth-kirjautuminen).
  Käytännössä tarjoat kyvykkyyden palveluna.

Alla vertailemme näitä käyttäjäkokemuksen, ekosysteemin saavuttavuuden sekä toimitus- ja ylläpitokustannusten näkökulmasta.

Käyttäjäkokemus#

Agent Skills yleensä tukeutuvat alustan API-rajapintoihin tai CLI-ohjelmiin. Käyttäjien täytyy ensin luoda API-avaimia tai asentaa ja kirjautua CLI-työkaluilla sisään. Vaiheet eivät ole monimutkaisia, mutta ne nostavat sisäänpääsyn kynnystä.

MCP-palvelimet tukevat OAuthia. Käyttäjät kirjautuvat SaaS-tilillään. Kokemus muistuttaa "Kirjaudu sisään Googlella" -toimintoa.

Käyttäjälle MCP-palvelimen käyttö on yksinkertaista: syötä URL, kirjaudu sisään, yhdistä. Tämä on kokemus, jonka haluamme tarjota.

Ekosysteemin kattavuus#

MCP-sivustolla on jo 104 tekoälysovellusta, jotka tukevat MCP:tä, mukaan lukien työkalut kuten VS Code, Cursor ja Windsurf.

Agent Skills ovat yhä alusta-spesifisiä. Vaikka moni alusta tukee niitä, kun julkaistaan MCP-palvelin, käyttäjät voivat käyttää sitä heti. Skill on vain sen tietyn alustan käyttäjien saatavilla.

MCP on mukana myös Agentic AI Foundation (AAIF) -alustalla. Se on protokollatasoinen standardi. Ekosysteemi kasvaa jatkuvasti. Meille tämä tekee MCP:stä pitkän tähtäimen sijoituksen arvoisen.

Toimitus- ja ylläpitokustannus#

Agent Skills nojaa alustan API-rajapintoihin tai CLI-ohjelmiin, mikä tuo nopeasti ongelmia:

• Mitä jos API muuttuu?
• Mitä jos CLI menettää taaksepäinyhteensopivuuden?
• Miten päivität ja jaat Skillin uudelleen?

Sinun täytyy myös jakaa CLI-ohjelmia, hallinnoida hajallaan olevia tunnistetietoja, tukea useita alustoja ja ohjata käyttäjiä päivittämään. Tuotto/hyötysuhde jää heikoksi.

MCP-palvelimet ovat paljon yksinkertaisempia. Käyttäjät yhdistävät URL:iin. Se osoittaa aina uusimpaan versioon. Kun päivitämme MCP-palvelimen, käyttäjät saavat sen seuraavalla kerralla, kun he yhdistävät. Päivityksiä ei tarvita. Jos Apit muuttuvat, päivitämme ne MCP-palvelimen sisällä.

Useimmilla SaaS-tuotteilla on jo vahva infrastruktuuri: toimivat API:t ja kehittynyt kirjautumisjärjestelmä. MCP-palvelin istuu luontevasti "tekoälyn rajapinnaksi" API:lle, kuten hallintakonsoli on toinen rajapinta samoille rajapinnoille.

Logton kohdalla MCP-palvelimen valinta istuu arkkitehtuuriimme ja hyödyntää vahvuuksiamme.

Se myös keskittää kaikki pyynnöt yhteen sisäänkäyntiin. Lokeeraus ja auditointi on helpompaa. Oikeudet ovat selkeät: tekoäly voi tehdä vain, mitä käyttäjä sallii. Tämä rakenne on siistimpi yritys- ja compliance-tilanteisiin.

Ongelmat, joihin törmäsimme toimittaessamme MCP-palvelinta, ja miten ratkoimme ne#

MCP ei ole täydellinen. Useimmat ongelmat liittyvät ekosysteemin kypsyyteen. Ne paranevat ajan myötä. Siihen asti käytämme kiertoteitä täyttääksemme todelliset tarpeet.

Hajautunut MCP-ominaisuuksien tuki#

MCP-määrittelyssä on monia ominaisuuksia, mutta asiakastuki vaihtelee:

• Työkalut: laajasti tuetut
• OAuth: hyvin tuettu VS Codessa; työkalut kuten Cursor tarvitsevat mcp-remote -sillan
• Muut ominaisuudet (Resurssit, Kehotukset, Ohjeet): epäyhtenäinen tuki

Nyt työkalut ovat luotettavin yhteinen kerros (katso MCP Community Page, mistä näet, mitä ominaisuuksia kukin asiakas tukee).

Strategiamme on siis yksinkertainen: rakennamme työkalujen varaan.

LLM ei tiedä, miten käyttää työkaluasi#

Tämä on liiketoimintakerroksen ongelma.

Agent Skillsissä liiketoimintalogiikka ja konteksti paketoidaan yhteen. LLM tietää, miten niitä käytetään. MCP toimittaa vain työkalut. Yhdistämisen jälkeen LLM ei tiedä:

• Käyttötapauksia
• Kutsujen järjestystä
• Liiketoimintarajoitteita

MCP:llä on Ohjeiden (Instructions) käsite, mutta kaikki asiakkaat eivät tue sitä. Ohjeet myös työntävät kaiken kontekstiin yhdistämishetkellä, mikä tuhlaa tokeneita.

Toinen idea on laittaa ohjeet työkalujen kuvauksiin. Tämä aiheuttaa kaksi ongelmaa:

• Kuvaukset monimutkaistuvat. Monityökaluiset työnkulut luovat sekavaa logiikkaa ja ovat vaikeita ylläpitää.
• Kun työkalujen määrä kasvaa, kuvaukset haukkaavat suuren osan konteksti-ikkunasta.

Meidän kiertotie: tarjoa getInstructions-työkalu

Idea on yksinkertainen: jos ohjeita ei tueta kunnolla, tee niistä työkaluja.

LLM voi kutsua getInstructions:ia tarpeen mukaan.
Tehtävässä A se kutsuu getTaskAInstructions. MCP-palvelin palauttaa kehotteen, joka kertoo, miten suoritetaan tehtävä A ja miten yhdistetään muita työkaluja.

Monimutkainen liiketoimintalogiikka pysyy ohjetyökalujen takana. Muut työkalut pysyvät yksinkertaisina. Työkalukuvaus kertoo vain työkalun oman tehtävän.

Tämä muistuttaa Agent Skillsiä: kehotteet ladataan tarpeen mukaan. Se on myös tehokkaampaa kuin globaalit ohjeet, sillä päästään eroon kaiken dumppaamisesta kontekstiin.

LLM voi vuotaa salaisuutesi#

Monille SaaS-tuotteille tiettyjen salaisuuksien vuotaminen on ehdoton ei (esim. client secrettit, API-avaimet tai webhook-allekirjoitusavaimet). Jos ne vuotavat, muut voivat esiintyä sinuna tai saada suoran pääsyn resursseihin.

LLM-tilanteessa chat ei ole turvallinen kanava. Viestit voivat tallentua, kopioitua, välittyä eteenpäin tai päätyä debug-lokeihin. Et voi olettaa "vain minä ja malli näemme tämän". Pitkäikäisen salaisuuden antaminen LLM:lle tai pyytäminen sitä tulostamaan salaisuus käyttäjälle kopiota varten on korkean riskin ratkaisu.

Tämä on tavallista verkkosovellusintegraatioissa: kehittäjä usein tarvitsee salaisuuden, laittaa sen palvelimen ympäristömuuttujiin tai konfiguraatiotiedostoihin ja viimeistelee vaiheet, kuten SDK:n alustuksen.

Jotta sisäänrakennus olisi helppoa ilman salaisuusturvallisuuden heikentämistä, teemme kolme asiaa:

• Käytä väliaikaisia salaisuuksia integraation aikana

  Keskustelupohjaisessa käyttöönotossa MCP-palvelin palauttaa vain lyhytikäisiä väliaikaisia salaisuuksia (esim. voimassa 1 tunti). Ne riittävät saamaan integraation käyntiin ja usein ne vanhenevat, ennen kuin menet tuotantoon. Ennen tuotantoa kehittäjät luovat ja korvaavat ne pitkäikäisillä tuotantosalaisuuksilla keskustelun ulkopuolella.

• Tuo turvaraja selvästi esiin

  Varoitamme käyttäjiä selkeästi: älä luo, liitä tai tallenna tuotantosalaisuuksia keskusteluun. Muistutamme myös kehittäjiä, että ympäristömuuttujat tai konfiguraatiotiedostotkin voivat vuotaa, jos agentti/LLM voi lukea niitä työkaluilla tai epäsuorasti. Laita tuotantosalaisuudet vain ympäristöihin, joissa tekoäly -avusteista integrointia ei käytetä.

• Älä käsittele tuotantosalaisuuksia keskustelussa; ohjaa käyttäjät konsoliin

  Pitkäikäisiä salaisuuksia ei luoda eikä jaella keskustelun kautta. Ne luodaan ja hallinnoidaan konsolin tunnistetietosivulla. Keskustelussa annamme vain suoran linkin konsoliin, jossa käyttäjä voi viimeistellä tuotantosalaisuuden asetukset.

Miten suunnittelemme MCP-työkaluja#

Meidän polkumme#

Logtolla on täysi Management API. Ensimmäinen ideamme oli yksinkertainen: altistetaan jokainen API-päätepiste MCP-työkaluna.

Tämä epäonnistui nopeasti.

Ensinnäkin kontekstin ylikuormitus. Logtolla on paljon API:ta. Yksi yhteen -vastaavuus täyttää konteksti-ikkunan. Jokainen työkalukuvaus maksaa tokeneita.

Toiseksi merkityksen katoaminen. API:t ovat kehittäjille tarkoitettuja atomisia rakennuspalikoita. Mutta Logto MCP-palvelimen käyttäjät eivät rakenna järjestelmiä. He haluavat vain tehdä tehtävän loppuun. Heitä ei kiinnosta API:en määrä.

Esimerkki: Logtolla on sign-in-experience-API brändäykseen, kirjautumismenetelmiin, rekisteröintitapoihin ja tietoturvapolitiikoihin.
Aluksi mietimme, miten altistaa kaikki parametrit LLM:lle. Miten opettaa yhdistämään kutsuja.

Mutta tämä on väärä ajattelutapa. Käyttäjät eivät tee API-kutsuja. He haluavat muuttaa brändäystä tai säätää kirjautumismenetelmiä.

Siksi työkalujen pitäisi olla updateBranding, updateSignInMethod, updateSignUpMethod. MCP-palvelin hoitaa API-yhdistelyn sisäisesti.

Logto MCP -palvelinta pitäisi käsitellä tuotteena, ei API-kääreenä. Se on "toinen hallintakonsoli".

Kuinka suunnitella MCP-työkaluja#

Sääntö selkiytyy:

• Jos käyttäjät käyttävät palveluasi suoraan (kuten konsolia), työkalut kannattaa tehdä liiketoimintalähtöisiksi.
• Jos tarjoat perustason kyvykkyyksiä muiden rakennettavaksi, työkalujen kannattaa olla atomisia ja yksinkertaisia. Esim. tiedostojärjestelmä-MCP-palvelin read_file, write_file, ja sitten koodausagentit yhdistävät ne.

Lisäperiaatteet:

• Pidä työkalulogiikka ja kuvaukset yksinkertaisina säästääksesi kontekstia.
• Monimutkaisille työnkuluille käytä getInstructions-työkaluja lataamaan ohjeet tarpeen mukaan. Myös niiden kuvaukset pidetään yksinkertaisina.

Odotuksemme MCP:n tulevaisuudelle#

Rakentaessamme MCP-palvelinta pohdimme myös, miten ekosysteemi voisi kehittyä.

Skill-tason kyvykkyyden toimitus#

Joskus MCP-palvelimen pitää tarjota työkalujen lisäksi ohjeet, miten yhdistää ne tehtäviksi, kuten Agent Skillsissä.

Tämä on tyypillistä SaaS-maailmassa. Esimerkiksi GitHub MCP Server, Logto MCP Server tai analytiikka-alustat. Käyttäjät haluavat työnkulkuja, eivät atomikutsuja.

getInstructions-työkalu on kiertotie. Protokollatason tuki olisi parempaa.

Sessiotason MCP-aktivointi#

Asiakkaat yhdistävät moniin MCP-palvelimiin, mutta kaikki eivät tarvitse jokaista istunnossa. Sessiotason päälle/pois-toiminnallisuus vähentäisi kontekstihukkaa.

Kontekstin eristäminen MCP-työkalukutsuissa#

Työkalukutsut vievät paljon kontekstia. Jos MCP-toiminnot hoidettaisiin aliagenteilla, pääkeskustelu voisi saada vain tiivistetyt tulokset.

Yhteenveto#

Tämä oli kokemuksemme etä-MCP-palvelimen rakentamisesta.

Jos tutkit tätä suuntaa, kokeile Logto MCP-palvelinta tai liity Discordiin vaihtamaan kokemuksia tosimaailman toteutuksista yhteisön kanssa.

Julkaisemme myös jatkossa arkkitehtuurisuunnitteluun ja OAuth-virtoihin liittyviä yksityiskohtia.