Kas ir ERP MCP serveris?

Serveris, kas pārvērš sistēmu par rīkiem

Model Context Protocol ir trīs lomas. Host ir AI lietojumprogramma, piemēram, Claude vai ChatGPT. Hostā tiek izveidots klients katram serverim un runā tikai ar šo serveri. Serveris ir pakalpojums, kas piedāvā kontekstu un iespējas hostam, izmantojot nelielu skaitu primitīvu. Specifikācijas dizaina principi nosaka, ka serveriem jābūt viegli izveidojamiem, kompozitīviem un nespēj redzēt visu sarunu vai citus serverus; host saglabā sarunu un nodrošina piekrišanu, serveris redz tikai tam adresētos zvanus.

Tādējādi ERP MCP serveris nav ERP. Tas ir ERP darbību virsma, izteikta kā rīki ar tipizētām ievadēm, kas tiek pasniegti vienā URL. Interesantais dizaina lēmums ir tas, kas ir rīks. Laika apstākļu serverim ir viens; biznesa sistēmai ir simtiem, un noderīgie ir darbības, ko persona var veikt (izveidot rēķinu, reģistrēt maksājumu, pārvietot darījumu, rezervēt krājumus), nevis rindas tabulās. Piemēram, Sois darba vietas serveris publicē rīkus ar nosaukumiem, piemēram, izveidot rēķinu, ierakstītMaksājumu, searchContacts un pārbaudīt kontaktinformācijusagrupēti pēc moduļiem, un precīza saraksta, ko saņem zvanu veicējs, atkarīga no tā, kas viņš ir.

Rīki, resursi un norādījumi

Specifikācija nosaka trīs servera primitīvus, un tie atšķiras pēc tā, kurš kontrolē to izmantošanu. Rīki ir modeļa kontrolēti: modelis nosaka, kad izsaukt vienu. Resursi ir lietojumprogrammas vadīti: host nosaka, kādu kontekstu pievienot, bieži ļaujot lietotājam izvēlēties no saraksta. Ieteikumi ir lietotāja kontrolēti veidnes. ERP nepieciešams pirmais, var gūt labumu no otrā, un reti nepieciešams trešais.

Divas rīku rezultātu iezīmes ir svarīgas biznesa sistēmai. Rīks var deklarēt izvades shēmu un atgriezt strukturētu saturu kas tam atbilst, kopā ar tekstu, ko modelis lasa, lai integrācija varētu izmantot rezultātu bez prozas analīzes. Un rīks, kas neizdodas biznesa iemesla dēļ (rēķins nepareizā stāvoklī, datums pagātnē, trūkstoša atļauja) atgriež normālu rezultātu ar isError: true un skaidrojumu, nevis protokola kļūdu, lai modelis varētu labot savu ievadi un mēģināt vēlreiz. Protokola kļūdas ir rezervētas nepareiziem pieprasījumiem un nezināmiem rīkiem.

Transports un pašreizējā specifikācija

Divi transporti ir standarta. Stdio ir serverim, ko klients palaidīs kā lokālu procesu, kas ir veids, kādā darbvirsmas rīki, piemēram, failu piekļuve, darbojas. Streamable HTTP ir paredzēts attālinātiem serveriem un to izmanto ERP: serveris izsaka vienu galapunktu, kas pieņem HTTP POST katram JSON-RPC ziņojumam un atbild ar vai nu JSON objektu, vai Server-Sent Events straumi, kas ir saistīta ar šo pieprasījumu, tādējādi garš izsaukums var nosūtīt progresu pirms tā galīgā rezultāta. Agrākais HTTP ar SSE transportu ir novecojis.

Pašreizējā revīzija, 2026-07-28, mainīja transportu tādā veidā, kas ir svarīgs ikvienam, kas izvieto serveri aiz slodzes līdzsvarotāja. Tā noņēma protokola līmeņa sesijas: vairs nav inicializācijas roku spiediena vai sesijas identifikatora galvenes, katrs pieprasījums nes savu protokola versiju un klienta iespējas savos metadatos, un serveris, kuram nepieciešama stāvokļa saglabāšana starp izsaukumiem, atgriež skaidru rokturi, ko modelis nodod atpakaļ kā argumentu. Serveri, kas rakstīti pret 2025-11-25 revīziju, kas izmantoja sesijas, turpina darboties, jo klientiem ir jāatpazīst vecā laikmeta un jāatgriežas; jaunam serverim nevajadzētu pieņemt sesijas.

Autorizācija: kam ir paredzēts zvans

HTTP transportiem specifikācija nosaka OAuth 2.1 plūsmu. Serveris ir resursu serveris un tam jāpublisko aizsargāto resursu metadati (RFC 9728), norādot uz savu autorizācijas serveri; kad pieprasījums ierodas bez tokena, tas atbild ar 401 un WWW-Authenticate galveni, kas norāda uz šo metadatu un, ideālā gadījumā, vismazāko nepieciešamo apjomu. Klients atklāj autorizācijas servera galapunktus, identificē sevi (klienta ID metadatu dokumenti ir ieteicamais ceļš; dinamiskā reģistrācija tiek saglabāta saderībai), veic autorizācijas koda plūsmu ar PKCE un tam jāiekļauj servera kanoniskā URI kā resursa parametrs, lai tokena saistīšana būtu tikai ar šo serveri. Serverim jāvalidē šī auditorija, jāatsaka tokeni, kas izsniegti citām vajadzībām, un tam nekad nevajadzētu nodot tokenu citai pakalpojumu.

Sekas ERP ir svarīgā. Tā kā tokena identificē personu, serveris var mainīt rezultātu tools/list pēc pieprasījuma akreditācijas datiem, un specifikācija to skaidri norāda. Tas ir mehānisms lomu balstītai filtrēšanai: finanšu lietotāja saraksts un noliktavas lietotāja saraksts nāk no viena un tā paša servera un ir atšķirīgi. Nepietiekams apjoms izpildes laikā tiek norādīts ar 403 un apjoma izaicinājumu, no kura klients var pacelties, lai gan lielākajai daļai uzņēmumu sistēmu reālā robeža ir loma ERP, nevis rupjais OAuth apjoms.

Grūtā daļa: atļaujas un darījumi

Viss iepriekš minētais var tikt īstenots vienā pēcpusdienā ar SDK. Tas, kas atšķir ERP MCP serveri no demonstrācijas, ir divu lietu apstrāde, ko protokols atstāj serverim: vai izsaukums ir atļauts un ko izsaukums nozīmē.

Atļauja ir jāpārbauda divreiz. Rīku saraksta filtrēšana novērš modeļa izvēli kaut ko, ko tas nedrīkst, kas ietaupa tokenus un neskaidrības. Pārbaude vēlreiz, kad rīks darbojas, ir faktiskā robeža, jo klients var nosūtīt jebkuru izsaukumu, ko vēlas. Noraidījums vislabāk tiek atgriezts kā rīka izpildes kļūda, lai modelis to izlasītu un ziņotu, nevis kā transporta kļūme, kas beidz pagriezienu. Šādi izskatās noraidīts izsaukums no Sois darba vietas: normāls rezultāts, atzīmēts, ar iemeslu.

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Tool not permitted for this account: approveInvoice requires the finance approver role."
      }
    ],
    "isError": true
  }
}

Atļaujas noraidījums tiek atgriezts kā rīka izpildes kļūda. Modelis uzzina, kāpēc un var lūgt personai apstiprināt; nekas netika uzrakstīts. Sois arī rezervē JSON-RPC kļūdu kodus neautorizētām sesijām, nepietiekamiem kredītiem, neļautiem rīkiem un sasniegtiem budžeta ierobežojumiem.

Transakcijas ir otrā puse. Rīkam jāatbilst vienai uzņēmējdarbības transakcijai ar skaidru pirms un pēc: izveidot rēķinu izveido melnrakstu ar identifikatoru, ierakstītMaksājumu veic vienu maksājumu vienam rēķinam, un neviens neatstāj pusrakstītu stāvokli, ja tas neizdodas. Modeļi atkārto, tāpēc rakstīšana jāveic droši atkārtot vai jāatsaka atkārtojums ar skaidru ziņojumu; specifikācijas anotācijas ļauj serverim deklarēt rīku kā tikai lasāmu, idempotentu vai destruktīvu, un tādi klienti kā ChatGPT izmanto šos norādījumus, kad izlemj, vai lūgt apstiprinājumu. Ja solim nepieciešama lēmuma pieņemšana, kas ir virs aģenta pilnvarām, serveris var atgriezt rezultātu, kas prasa ievadi, uzdodot personai jautājumu caur klientu, nevis minot.

Kā Sois to īsteno

Sois darba vide ir MCP serveris ar vienu URL, darba vides adrese, kas seko pēc: /api/mcp. It answers the 401 challenge with protected resource metadata, publishes its authorisation server metadata, requires PKCE, and issues tokens scoped to the workspace; a connector in Claude or ChatGPT completes the sign-in with nothing pasted. A bearer token with an API key is available for scripts that do not do OAuth, with identity and spend held in separate credentials on purpose.

Rīku saraksts tiek ģenerēts no dzīvajām rīku definīcijām un filtrēts pēc lomas un instalētajām lietotnēm, pēc tam katra izsaukuma atļaujas tiek pārbaudītas izpildes laikā un tas tiek slēgts, ja nav atļauts. Izsaukumi ir ierobežoti pēc savienojuma, mērīti, ja darba telpas paša aģents veic loģiku, un bez AI maksām, ja izsaukuma veicēja aģents to dara, ierobežoti ar budžetu, ko nosaka darba telpa, un reģistrēti ar ievadiem un rezultātiem pret personu, kas tos veica. Lietotnes, kas publicētas tirgū, pievieno savus rīkus tajā pašā sarakstā saskaņā ar tiem pašiem noteikumiem, tāpēc izstrādātāja lietotne ir darbināma ar aģentu brīdī, kad tā tiek instalēta.

Cilvēki uzdod jautājumus

Šis raksts tiek pārskatīts, kad mainās tajā aprakstītie produkti. Nākamais plānotais pārskats: 2026. gada 4. decembris.