Wat is een ERP MCP-server?

Een server die een systeem in tools omzet

Het Model Context Protocol heeft drie rollen. Een host is een AI-toepassing zoals Claude of ChatGPT. Binnen de host wordt er per server een client aangemaakt die alleen met die server communiceert. Een server is een dienst die context en mogelijkheden aan de host biedt via een klein aantal primitieve elementen. De ontwerpbeginselen van de specificatie stellen dat servers gemakkelijk te bouwen, samenstelbaar en niet in staat moeten zijn om het hele gesprek of andere servers te zien; de host houdt het gesprek en handhaaft toestemming, de server ziet alleen de oproepen die aan haar zijn gericht.

Een ERP MCP-server is daarom niet de ERP. Het is het actieoppervlak van de ERP, uitgedrukt als tools met getypte invoer, aangeboden op één URL. De interessante ontwerpe beslissing is wat een tool is. Een weerserver heeft er één; een bedrijfsysteem heeft er honderden, en de nuttige zijn acties die een persoon kan ondernemen (een factuur aanmaken, een betaling registreren, een deal verplaatsen, voorraad reserveren) in plaats van rijen in tabellen. De werkruimte server van Sois publiceert bijvoorbeeld tools met namen zoals maakFactuur, registreerBetaling, searchContacts en examineerContact, grouped by module, and the exact list a caller receives depends on who they are.

Tools, middelen en prompts

De specificatie definieert drie serverprimitieven, en ze verschillen in wie hun gebruik controleert. Tools zijn modelgestuurd: het model beslist wanneer er een wordt aangeroepen. Resources zijn applicatiegestuurd: de host beslist welke context eraan moet worden gekoppeld, vaak met de gebruiker die uit een lijst kiest. Prompts zijn door de gebruiker gecontroleerde sjablonen. Een ERP heeft de eerste nodig, kan profiteren van de tweede, en heeft zelden de derde nodig.

Twee kenmerken van toolresultaten zijn belangrijk voor een bedrijfsysteem. Een tool kan een outputSchema en terug structuredContent dat eraan voldoet, samen met de tekst die een model leest, zodat een integratie het resultaat kan gebruiken zonder proza te parseren. En een tool die om zakelijke redenen faalt (een factuur in de verkeerde staat, een datum in het verleden, een ontbrekende toestemming) retourneert een normaal resultaat met isError: true en een uitleg, in plaats van een protocolfout, zodat het model zijn invoer kan corrigeren en het opnieuw kan proberen. Protocolfouten zijn gereserveerd voor onjuiste verzoeken en onbekende tools.

Het transport en de huidige specificatie

Twee transportmethoden zijn standaard. Stdio is voor een server die de cliënt als een lokaal proces opstart, wat is hoe desktoptools zoals bestands toegang werken. Streamable HTTP is voor externe servers en is wat een ERP gebruikt: de server biedt één eindpunt dat een HTTP POST per JSON-RPC-bericht accepteert en antwoordt met ofwel een JSON-object of een Server-Sent Events-stroom die is afgebakend voor dat verzoek, zodat een lange oproep voortgang kan verzenden voordat het uiteindelijke resultaat binnenkomt. Het eerdere HTTP met SSE-transport is verouderd.

The current revision, 2026-07-28, changed the transport in a way that matters for anyone deploying a server behind a load balancer. It removed protocol-level sessions: there is no longer an initialize handshake or a session identifier header, every request carries its protocol version and client capabilities in its own metadata, and a server that needs state across calls returns an explicit handle the model passes back as an argument. Servers written against the 2025-11-25 revision, which did use sessions, keep working because clients are required to detect the older era and fall back; a new server should not adopt sessions.

Autorisatie: voor wie de oproep is

Voor HTTP-transporten definieert de specificatie een OAuth 2.1-stroom. De server is een resource server en moet metadata van beschermde bronnen publiceren (RFC 9728) waarin zijn autorisatieserver wordt genoemd; wanneer een verzoek zonder token binnenkomt, antwoordt het met 401 met een WWW-Authenticate-header die naar die metadata wijst en, idealiter, de minste benodigde scope. De client ontdekt de eindpunten van de autorisatieserver, identificeert zichzelf (documenten met client-ID-metadata zijn de aanbevolen route; dynamische registratie blijft behouden voor compatibiliteit), voert een autorisatiecode-stroom uit met PKCE en moet de canonieke URI van de server opnemen als de resourceparameter, zodat de token alleen aan deze server is gebonden. De server moet dat publiek valideren, moet tokens weigeren die voor iets anders zijn uitgegeven en mag nooit een token doorgeven aan een andere service.

De consequentie voor een ERP is de belangrijke. Omdat de token een persoon identificeert, kan de server het resultaat van tools/lijst by the credentials on the request, and the specification says so explicitly. That is the mechanism for role-based filtering: a finance user's list and a warehouse user's list come from the same server and are different. Insufficient scope at runtime is signalled with a 403 and a scope challenge the client can step up from, though for most business systems the real boundary is the role in the ERP rather than the coarse OAuth scope.

Het moeilijke deel: machtigingen en transacties

Alles hierboven kan in een middag worden geïmplementeerd met een SDK. Wat een ERP MCP-server van een demo onderscheidt, is de behandeling van de twee zaken die het protocol aan de server overlaat: of een oproep is toegestaan en wat een oproep betekent.

Toestemming moet twee keer worden gecontroleerd. Het filteren van de hulplijst voorkomt dat het model iets kiest dat het niet zou moeten kiezen, wat tokens en verwarring bespaart. Nogmaals controleren wanneer de tool draait, is de werkelijke grens, omdat een klant elke oproep kan verzenden die hij wil. Een weigering wordt het beste teruggegeven als een fout bij de uitvoering van de tool, zodat het model deze leest en rapporteert, in plaats van als een transportfout die de beurt beëindigt. Dit is hoe een geweigerde oproep eruitziet vanuit een Sois-werkruimte: een normaal resultaat, gemarkeerd, met een reden.

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

Een toestemming weigering werd teruggegeven als een fout bij het uitvoeren van de tool. Het model leert waarom en kan de persoon vragen om goedkeuring; er is niets geschreven. Sois reserveert ook JSON-RPC foutcodes voor niet-geautoriseerde sessies, onvoldoende tegoeden, niet-toegestane tools en bereikte budgetlimieten.

Transacties zijn de tweede helft. Een tool moet overeenkomen met één zakelijke transactie met een duidelijk voor en na: maakFactuur produceert een concept met een identificator, registreerBetaling past één betaling toe aan één factuur, en laat geen halfgeschreven staat achter als het mislukt. Modellen proberen opnieuw, dus schrijfacties moeten veilig zijn om te herhalen of moeten een herhaling weigeren met een duidelijke boodschap; de annotaties in de specificatie laten een server een tool als alleen-lezen, idempotent of destructief verklaren, en clients zoals ChatGPT gebruiken die aanwijzingen bij het beslissen of ze om bevestiging moeten vragen. Waar een stap een beslissing vereist die boven de autoriteit van de agent ligt, kan de server een invoervereiste resultaat teruggeven waarin de persoon een vraag wordt gesteld via de client, in plaats van te gokken.

Hoe Sois er een implementeert

Een Sois-werkruimte is een MCP-server op een enkele URL, het adres van de werkruimte gevolgd door /api/mcp. Het beantwoordt de 401-uitdaging met metadata van beschermde bronnen, publiceert de metadata van zijn autorisatieserver, vereist PKCE en geeft tokens uit die zijn afgestemd op de werkruimte; een connector in Claude of ChatGPT voltooit de aanmelding zonder iets te plakken. Een bearer-token met een API-sleutel is beschikbaar voor scripts die geen OAuth gebruiken, waarbij identiteits- en uitgaveninformatie opzettelijk in aparte referenties wordt bewaard.

De lijst met tools wordt gegenereerd uit de live tooldefinities en gefilterd op rol en geïnstalleerde apps. Elke oproep wordt bij uitvoering gecontroleerd op toestemming en faalt gesloten. Oproepen zijn per verbinding beperkt, gemeten waar de eigen agent van de werkruimte de redenering doet en vrij van AI-kosten waar de eigen agent van de beller dat doet, met een limiet die de werkruimte instelt, en gelogd met invoer en resultaten tegen de persoon die ze heeft gemaakt. Apps die op de marketplace zijn gepubliceerd, voegen hun tools toe aan dezelfde lijst onder dezelfde regels, zodat de app van een ontwikkelaar door een agent kan worden gebruikt op het moment dat deze is geïnstalleerd.

Vragen die mensen stellen

Dit artikel wordt herzien wanneer de producten die het beschrijft veranderen. Volgende geplande herziening: 4 december 2026.