Model Context Protocol on avoin standardi sille, miten tekoälysovellus saa yhteyden yrityksen järjestelmiin ja tietoon. Johdon kysymys ei ole protokolla vaan se, kuka päättää mihin sovellus pääsee käsiksi — ja miten sen näkee jälkikäteen.
Kirjoittaja Sami Matias Breilin — päivitetty 15.9.2026
MCP (Model Context Protocol) on avoin standardi, joka määrittelee miten tekoälysovellus keskustelee ulkoisten tietolähteiden ja työkalujen kanssa. Ilman yhteistä standardia jokainen yhteys järjestelmään rakennetaan erikseen ja kertakäyttöisesti. MCP:n kanssa yhteys on samanmuotoinen riippumatta siitä, mihin järjestelmään se menee. Yritykselle merkitys on hallinnollinen ennen kuin se on tekninen: samanmuotoiset yhteydet voi luetteloida, katselmoida ja sulkea. MCP ei kuitenkaan päätä kuka saa tehdä mitä — se päätös on yhä yrityksen.
Model Context Protocol on avoin protokolla, joka kuvaa yhden asian: miten tekoälysovellus ja ulkopuolinen tietolähde tai työkalu vaihtavat tietoa keskenään. Se ei ota kantaa siihen, mitä kielimallia sovellus käyttää eikä siihen, miten sovellus hyödyntää saamaansa tietoa.
Vertauskuva, joka kestää tarkastelun: MCP on liitäntästandardi samaan tapaan kuin yhtenäinen pistoke on liitäntästandardi. Se ei tee laitteesta parempaa. Se tekee siitä liitettävän ilman erillistä sovitinta joka kerta.
Käytännön ero näkyy ylläpidossa. Ilman standardia yhteydet toiminnanohjaukseen, tikettijärjestelmään ja tiedostoarkistoon ovat kolme erillistä rakennelmaa, joilla on kolme eri tekijää ja kolme eri tapaa hajota. Standardin kanssa ne ovat kolme samanmuotoista yhteyttä, joita voi katselmoida samalla listalla.
MCP noudattaa asiakas–palvelin-mallia, jossa on kolme roolia. Roolit kannattaa erottaa toisistaan, koska vastuu ja valvonta kohdistuvat eri kohtiin.
| Osa | Mikä se on | Mitä se tarkoittaa yritykselle |
|---|---|---|
| MCP-isäntä (host) | Tekoälysovellus, joka koordinoi yhtä tai useampaa asiakasta | Tämä on se työkalu, jota työntekijä käyttää — ja jonka hankinnasta päätetään |
| MCP-asiakas (client) | Osa, joka ylläpitää yhteyttä yhteen palvelimeen ja hakee siltä tietoa isännän käyttöön | Yhteyksiä on yksi kutakin palvelinta kohti, joten ne ovat laskettavissa |
| MCP-palvelin (server) | Ohjelma, joka tarjoaa tietoa ja toimintoja asiakkaille | Tämä on se kohta, jossa pääsy yrityksen järjestelmään todella tapahtuu |
Isäntä luo erillisen asiakkaan jokaista palvelinta kohti, ja jokainen asiakas pitää yllä omaa yhteyttään. Tästä seuraa hallinnan kannalta hyödyllinen ominaisuus: yhteydet eivät ole yksi jakamaton kokonaisuus vaan laskettava joukko, joka voidaan kirjata agenttirekisteriin yksi kerrallaan.
Palvelin voi olla paikallinen tai etäpalvelin. Paikallinen palvelin toimii samalla koneella kuin sovellus ja käyttää stdio-yhteyttä eli prosessien välistä suoraa viestintää. Etäpalvelin toimii verkon yli ja käyttää Streamable HTTP -yhteyttä. Ero on olennainen tietosuojan kannalta: paikallinen palvelin ei siirrä tietoa koneelta pois, etäpalvelin siirtää.
MCP:n tietokerros käyttää JSON-RPC 2.0 -protokollaa. Yhteys alkaa neuvottelulla, jossa asiakas ja palvelin kertovat toisilleen mitä ominaisuuksia ne tukevat. Etäyhteyksissä käytetään tavanomaisia HTTP-todennustapoja, ja standardi suosittelee OAuthia todennustietojen hankkimiseen. Tämä on se kohta, jossa yrityksen omat pääsynhallintasäännöt kytkeytyvät mukaan.
Palvelin voi tarjota kolmea asiaa. Ero niiden välillä on yrityksen kannalta tärkeämpi kuin miltä se aluksi vaikuttaa, koska vain yksi niistä tekee jotain.
| Tarjottava | Mitä se on | Riskiluonne |
|---|---|---|
| Työkalut (tools) | Suoritettavia toimintoja, joita sovellus voi kutsua: tiedosto-operaatioita, rajapintakutsuja, tietokantakyselyitä | Tekee jotain. Tähän kohdistuu valtuuskysymys. |
| Resurssit (resources) | Tietolähteitä, jotka tuovat taustatietoa sovellukselle: tiedostojen sisältöä, tietueita, rajapintavastauksia | Lukee. Tähän kohdistuu tietosuojakysymys. |
| Kehotteet (prompts) | Uudelleenkäytettäviä ohjepohjia, jotka jäsentävät vuorovaikutusta mallin kanssa | Ohjaa. Tähän kohdistuu laatukysymys. |
Sovellus hakee saatavilla olevat työkalut erillisellä listauskutsulla (tools/list) ennen kuin se kutsuu mitään, ja suorittaa valitsemansa työkalun omalla kutsullaan (tools/call). Listaus on dynaaminen: palvelin voi ilmoittaa asiakkaalle, että sen työkaluvalikoima on muuttunut.
Tämä on hallinnan kannalta se kohta, joka kannattaa ymmärtää. Palvelimen tarjoama työkaluvalikoima voi muuttua ilman että yrityksessä tehdään mitään uutta päätöstä. Siksi ulkopuolisen palvelimen kohdalla pelkkä käyttöönottohetken tarkastus ei riitä — tarvitaan katselmusrytmi.
Standardi ratkaisee kapean mutta kalliin ongelman. On hyödyllistä tietää kumpaan puoleen oma kysymys kuuluu ennen kuin hanke aloitetaan.
Oikean laatikon ensimmäinen kohta on tärkein. Standardi tekee pääsystä teknisesti helpompaa, mikä on nimenomaan syy pitää valtuusrajat kunnossa ennen käyttöönottoa eikä sen jälkeen. Helppo yhteys ilman sovittua valtuustasoa on nopein tunnettu tapa saada pääsyjä, joita kukaan ei muista myöntäneensä.
Järjestys on tärkeämpi kuin nopeus. Nämä viisi askelta ovat tehtävissä ilman uutta järjestelmähankintaa.
Ja erikseen: mitkä eivät ole. Sallittujen järjestelmien luettelo on lyhyempi ja huomattavasti helpompi valvoa kuin yritys luetella kaikki kielletyt.
Aloita resursseista eli lukemisesta. Työkalut, jotka kirjoittavat tai muuttavat tietoa, ovat oma erillinen päätöksensä, ja ne kytketään vasta kun lukukäyttö on osoittautunut hyödylliseksi.
Jokainen yhteys tunnistautuu omilla tunnuksillaan, ei jaetulla tunnuksella. Jaettu tunnus tarkoittaa, ettei jäljestä voi päätellä, mikä yhteys teki mitä.
Mikä järjestelmä, mikä palvelin, kuka omistaa, mikä valtuustaso, milloin katselmoidaan. Yksi rivi yhteyttä kohti riittää.
Ulkopuolisen palvelimen tarjonta voi muuttua ilman erillistä ilmoitusta. Neljännesvuosittainen tarkistus riittää useimmille.
Askeleet 4 ja 5 ovat samat kuin kaikilla muillakin agenteilla. Jos ne ovat jo olemassa, MCP ei tuo uutta hallintotyötä — se tuo vain uusia rivejä samaan listaan. Jos niitä ei ole, lue ensin agenttien leviämisestä.
Standardi kannattaa ottaa käyttöön silloin, kun se maksaa itsensä takaisin. Aina se ei sitä tee.
Kun yhteyksiä on yksi. Yhden järjestelmän yhteys yhteen sovellukseen on nopeampi rakentaa suoraan. Standardin hyöty syntyy toistosta, ei ensimmäisestä kerrasta.
Kun perustieto on epäkunnossa. Jos järjestelmän tiedot ovat puutteellisia, niiden saatavuuden helpottaminen levittää ongelman useampaan paikkaan. Korjaa tieto ensin.
Kun ongelma on prosessissa. Jos työ takkuaa siksi, ettei kukaan tiedä kuka päättää mitä, yhteys järjestelmään ei muuta sitä. Sama koskee tilannetta, jossa pilotti ei skaalaudu organisatorisista syistä.
Kun valtuuskysymys on ratkaisematta. Tämä ei ole syy jättää standardia käyttämättä, mutta se on syy olla kiirehtimättä. Ratkaise valtuustasot ensin, kytke yhteydet sitten.
Mikä MCP on?
Model Context Protocol on avoin standardi, joka määrittelee miten tekoälysovellus keskustelee ulkoisten tietolähteiden ja työkalujen kanssa. Se ei ota kantaa siihen, mitä kielimallia sovellus käyttää tai miten se hyödyntää saamaansa tietoa.
Mitkä ovat MCP:n kolme osaa?
Isäntä on tekoälysovellus, joka koordinoi yhteyksiä. Asiakas on osa, joka ylläpitää yhteyttä yhteen palvelimeen. Palvelin on ohjelma, joka tarjoaa tietoa ja toimintoja. Isäntä luo erillisen asiakkaan jokaista palvelinta kohti.
Mitä MCP-palvelin voi tarjota?
Kolmea asiaa: työkaluja eli suoritettavia toimintoja, resursseja eli taustatietoa tuovia tietolähteitä ja kehotteita eli uudelleenkäytettäviä ohjepohjia. Vain työkalut tekevät jotain, joten valtuuskysymys kohdistuu niihin.
Onko MCP tietoturvaratkaisu?
Ei. MCP määrittelee miten yhteys muodostetaan ja miten viestit kulkevat, ja etäyhteyksissä standardi suosittelee OAuthia todennustietojen hankkimiseen. Päätös siitä, mihin agentti pääsee käsiksi ja mitä se saa tehdä, on yhä yrityksen oma.
Mitä eroa on paikallisella ja etäpalvelimella?
Paikallinen palvelin toimii samalla koneella kuin sovellus ja käyttää stdio-yhteyttä. Etäpalvelin toimii verkon yli ja käyttää Streamable HTTP -yhteyttä. Tietosuojan kannalta ero on se, siirtyykö tieto koneelta pois vai ei.
Milloin MCP ei kannata ottaa käyttöön?
Kun yhteyksiä on vain yksi, kun järjestelmän perustieto on epäkunnossa tai kun ongelma on prosessissa eikä tiedon saatavuudessa. Hyöty syntyy toistosta, joten ensimmäinen yhteys on lähes aina nopeampi rakentaa suoraan.
MCP tekee pääsystä teknisesti helppoa. Juuri siksi kannattaa päättää ennen käyttöönottoa, mihin pääsy ulottuu ja kuka sen katselmoi.
Katso valtuustasot