Cognitieve automatisering: automatisering van kenniswerk
De MCP-tools in btlabs Core verbinden taalmodellen op een gecontroleerde manier met content en systeemfuncties. Dit artikel legt de rollen, MCP-toegangsrechten, menselijke goedkeuringen, tenantscheiding en auditlogboeken uit voor experts.

De MCP-tools van btlabs Core combineren een taalmodel met inhoud en beperkte systeemfuncties op een gecontroleerde manier: het taalmodel kan een toolaanroep suggereren, de MCP-client beheert machtigingen en toegang, en de MCP-server voert de geautoriseerde aanroep uit. Cruciaal is dat niet alleen de technische beschikbaarheid van belang is, maar ook welke tool voor welke client, rol en doel is geautoriseerd.

Het Model Context Protocol (MCP) standaardiseert de verbinding tussen applicaties met taalmodellen en externe data of functies. In btlabs Core zijn MCP-tools ontworpen om repetitief werk te verminderen zonder onbedoeld releases, rechtenwijzigingen of andere belangrijke beslissingen te veroorzaken.

Een item in de toolcatalogus is een technisch aanbod. Alleen een geschikte rechtenklasse, een toegestaan ​​doel en een gedocumenteerde release-status maken het daadwerkelijke gebruik van de tool operationeel toegestaan.

MCP-tools in btlabs Core: rollen en workflow

De MCP-architectuur maakt onderscheid tussen host, client en server. In de gebruikte specificatieversie, gedateerd 28 juli 2026, coördineert de host de clients en de beveiligingsregels. Elke MCP-client communiceert met een specifieke MCP-server, terwijl de server tools en andere functies levert.

  • Taalmodel: Het model interpreteert de taak en kan een geschikt hulpmiddel suggereren. Het taalmodel levert het hulpmiddel niet en verleent geen machtigingen.
  • host: De applicatie coördineert het taalmodel, MCP-clients, gebruikersinteractie en beveiligingsregels.
  • MCP-client: De client verbindt de host met een MCP-server, verwerkt de zichtbare toolcatalogus en verzendt toegestane aanroepen.
  • MCP-server: De server biedt gedefinieerde MCP-tools en voert aanroepen uit binnen de verleende machtigingen.
  • Verantwoordelijke persoon: Mensen beoordelen gevoelige of ingrijpende handelingen en keuren de uitvoering ervan goed of af.

Een gecontroleerd gesprek verloopt in zeven stappen:

  1. Een gebruiker of het taalmodel suggereert een taak.
  2. De MCP-client voert query's uit met tools/lijst de instrumenten die in de huidige context zichtbaar zijn.
  3. De client controleert de client, rol, rechtenklasse, doel en vrijgavestatus.
  4. Voor handelingen die goedkeuring vereisen, vraagt ​​de gastheer om menselijke toestemming.
  5. De MCP-client verzendt het bevestigde gesprek met gereedschap/oproep naar de MCP-server.
  6. De MCP-server voert de tool uit en retourneert een resultaat of een foutmelding.
  7. Het gesprek, het resultaat, de versiestatus en de vrijgavebeslissing worden vastgelegd in het auditlogboek.

De operationele context moet worden vastgesteld aan de hand van unieke identiteiten, rollen, klantgegevens, parameters en machtigingen. Eerder verleende toestemming mag niet automatisch gelden als toestemming voor een volgend verzoek.

Referentiestatus van de btlabs MCP-toolcatalogus

Een betrouwbare MCP-toolcatalogus voor btlabs Core moet rechtstreeks worden gegenereerd vanuit de geïmplementeerde omgeving. Hoewel de bedrijfsgegevens een technisch eindpunt voor tools specificeren, bevatten ze geen geverifieerde export met toolnamen, machtigingen en versie-informatie. Daarom geeft dit artikel geen vast totaal aantal of een lijst met onbevestigde namen van vermeende geïmplementeerde btlabs MCP-tools.

  • product: btlabs Core
  • Productversie: niet weergegeven in de huidige dataset
  • Versie van de gereedschapscatalogus: niet weergegeven in de huidige dataset
  • Technische exportdeadline: niet weergegeven
  • Verantwoordelijke technische beoordeling: niet weergegeven
  • Individueel gevalideerde MCP-toolnamen: Documentatie is niet mogelijk zonder een geverifieerde serverexport.

Totdat een dergelijke export beschikbaar is, beschrijft het artikel een model voor governance en documentatie. De genoemde functionele gebieden vormen geen toezegging met betrekking tot individuele MCP-eindpunten.

Verplichte informatie voor elk echt gereedschap

Elke vermelding in de MCP-toolcatalogus moet ten minste de volgende informatie bevatten:

  • Technische naam: Unieke naam voor gereedschap/oproep
  • Operationele taak: begrijpelijke beschrijving van het specifieke doel
  • Gegevensbereik: toegankelijke inhoud, velden of systeemstatussen
  • Rechtenklasse: Lezen, schrijven, uitvoeren of beheren
  • Releasestatus: automatisch toegestaan, onder voorbehoud van toestemming, beperkt of uitgeschakeld
  • Externe invloed: mogelijke publicatie, communicatie, gegevensdeling of systeemwijziging
  • Klantrelatie: duidelijk gedefinieerde data- en autorisatieruimte
  • Versie: Productversie en tooldefinitieversie
  • Termijn: Datum van de laatste technische keuring

In het artikel over de architectuur van btlabs Core leg ik de technische structuur van de centrale content- en dataopslagplaats uit . De gedeelde database is ontworpen om te voorkomen dat de website, taalversies en machineleesbare output verschillende bedrijfsgegevens gebruiken.

Interne functies zijn niet automatisch MCP-tools.

Een interne systeemfunctie, een gebruikersinterface en een tool die toegankelijk is via MCP zijn drie verschillende dingen. Daarom kan een functie alleen als beschikbare MCP-tool worden aangewezen als de huidige servercatalogus de technische naam, parameters en releasestatus ervan vermeldt.

Pas na technische verificatie als MCP-tool aanwijzen.

  • Het lezen van een specifiek inhoudsrecord via een benoemde MCP-aanroep.
  • Een niet-openbaar concept maken of bijwerken
  • Gerelateerde taalversies controleren
  • Het uitvoeren van een SEO-, GEO- of volledigheidscontrole.
  • Een releasestatus of auditlogboek opvragen
  • Het in gang zetten van een publicatie- of beheerproces

De voorbereide uitbreidingsfasen vormen geen bindende productverplichting.

  • AI-boekingsagenten
  • Winkel- en voorraadfuncties
  • beveiligde klantgebieden
  • Live prijsberekening en afspraakweergave
  • Apps of andere locaties gebaseerd op dezelfde gegevens

Een technisch voorbereide functie wordt niet automatisch geactiveerd of vrijgegeven. Het specifieke project, de implementatie en de actuele toolcatalogus blijven doorslaggevend.

tools/list toont de tools, maar verleent geen machtigingen.

Met het commando `tools/list` worden de tools opgevraagd die de MCP-server aanbiedt. De MCP-toolspecificatie maakt het mogelijk dat het zichtbare bereik afhangt van de ingediende autorisatie en de verleende machtigingen.

Voor btlabs Core zou `tools/list` alleen de MCP-tools moeten weergeven die de huidige tenant en rol mogen zien. Of een specifieke installatie al op deze manier filtert, moet worden bevestigd door een technische test op de gedocumenteerde einddatum.

tools/list beantwoordt de vraag: "Welke tools worden mij aangeboden?" Het antwoord geeft niet automatisch toestemming voor elk mogelijk effect van deze tools.

De opdracht `tools/call` stuurt de toolnaam en de vereiste argumenten naar de MCP-server. Vóór de uitvoering moeten de identiteit, client, machtigingsklasse en vrijgavestatus overeenkomen met de geplande aanroep.

Vier MCP-privilegeklassen voor btlabs Core

De vier MCP-rechtenklassen vormen een operationeel governance-model voor btlabs Core. De MCP-specificatie definieert deze klassen niet als normatieve autorisatieniveaus.

  • Lees: Zoek, bekijk, vergelijk en beoordeel content zonder gegevens of voorwaarden te wijzigen.
  • Schrijven: Je kunt concepten maken, velden bijwerken of opdrachten wijzigen. Dit recht omvat niet automatisch het publiceren of verwijderen van documenten.
  • Uitvoeren: Een beperkt proces starten, zoals een inspectie of een omkeerbare bewerkingsstap.
  • Beheren: Wijzig rollen, rechten, exporten, wereldwijde instellingen of systeemwijde statussen.

Toestemmingen worden verleend volgens het principe van minimale bevoegdheden : een gebruiker, service of agent ontvangt alleen de rechten die nodig zijn voor een duidelijk omschreven taak. De toestemming geldt voor een specifieke client, gedefinieerde gegevensgebieden en, waar mogelijk, een beperkte tijdsperiode.

Mijn werk met kleine bedrijven laat regelmatig zien dat te ruime standaardrollen meer risico's met zich meebrengen dan duidelijk gedefinieerde instrumenten. Een redactieproces wordt niet veiliger door simpelweg alle deelnemers uit voorzorg beheerdersrechten te geven.

Clientscheiding beschermt gegevens en verantwoordelijkheden.

Clientscheiding voorkomt dat een tool gegevens van verschillende bedrijven, websites of organisatie-eenheden combineert. Een MCP-oproep voor bedrijf A mag geen inhoud van bedrijf B zien, noch de gedeelde mappen of logboeken ervan gebruiken.

  • Elke aanvraag vereist een unieke klantidentificatie.
  • Rollen en rechten worden per klant toegewezen.
  • De toegang tot gegevens en de bijbehorende protocollen blijven gescheiden.
  • Eerdere goedkeuringen kunnen niet worden overgedragen naar een andere klantcontext.
  • Het gesprek wordt afgebroken als er een conflicterende client- of rolreferentie is.

Een gemeenschappelijke gebruikersinterface mag de beveiligingsgrenzen van individuele bedrijven niet verzwakken.

Welke MCP-tools vereisen menselijke goedkeuring?

De specificatie van de MCP-tool schrijft geen specifiek interactiemodel voor. Wel worden zichtbare tooloproepen, bevestigingsdialoogvensters en een menselijke gebruiker met de mogelijkheid om te weigeren aanbevolen. Voor btlabs Core resulteert dit in een strikter operationeel model voor acties met gevolgen.

Voor de volgende zaken is nog steeds menselijke goedkeuring vereist:

  • Publicaties: De inhoud wordt openbaar zichtbaar.
  • Definitieve verwijderingen: Gegevens kunnen verloren gaan en verbindingen kunnen verbroken worden.
  • Wijzigingen in rechten: Het beveiligingskader voor volgende aanroepen wordt gewijzigd.
  • Export: Gegevens kunnen het beoogde verwerkingsgebied verlaten.
  • Externe communicatie: E-mails, aanbiedingen of boekingen kunnen zakelijke gevolgen hebben.
  • Systeemwijde interventies: Wereldwijde veranderingen kunnen gevolgen hebben voor diverse soorten content, talen of websites.

De autorisatie moet specificeren welke tool welke gegevens verwerkt en met welk beoogd effect. Een algemene toestemming zonder doel, reikwijdte en geldigheidsperiode is onvoldoende.

Wat een auditlogboek moet documenteren

Een auditlogboek maakt toolaanroepen, fouten en releasebeslissingen traceerbaar. Het logboek mag alleen informatie vastleggen die nodig is voor beveiliging, foutanalyse en verantwoording.

  • Identiteit: triggerende gebruiker, service of agent
  • Cliënt: Betrokken gegevens en verantwoordelijkheidsgebied
  • Hulpmiddel: Technische naam en toolversie
  • Tijd: Begin, einde en duur van het gesprek
  • Rechtenklasse: gebruikt autorisatieniveau
  • Releasestatus: goedgekeurd, bevestigd, afgewezen of verlopen
  • Parameter: Vereiste invoergegevens in een gegevensminimaliserende vorm.
  • Resultaat: Wijziging, retourzending, annulering of fout
  • Besluit tot vrijlating: verantwoordelijke persoon en tijdstip
  • Versie: Versie van btlabs Core en toolcatalogus

Wachtwoorden, toegangstokens, beveiligingssleutels en onnodige persoonlijke gegevens horen niet thuis in het auditlogboek. Traceerbaarheid en dataminimalisatie moeten hand in hand gaan.

Praktisch voorbeeld: Gecontroleerde actualisering van meertalige content

Vorige: Wijzigingen werden meerdere keren overgedragen

Een klein toeristisch bedrijf actualiseert zijn openingstijden en servicebeschrijvingen in het Duits en Italiaans. Een medewerker zoekt de relevante pagina's op, voert elke wijziging afzonderlijk door en controleert de metadata en taalkoppelingen. Het is mogelijk dat verouderde informatie in één van de taalversies blijft staan.

Daarna: controleren, opslaan als concept en publiceren

  1. De medewerker selecteert de inhoud en de geschikte klant.
  2. De MCP-client gebruikt tools/list om de MCP-tools op te halen die zichtbaar zijn voor de redactierol.
  3. Een gevalideerd leesinstrument vergelijkt de Duitse en Italiaanse inhoud.
  4. Het taalmodel wijst op mogelijke inconsistenties en doet suggesties voor verbeteringen.
  5. Een schrijfprogramma creëert uitsluitend niet-openbare concepten.
  6. Een verificatietool controleert feiten, taalrelaties, metadata en verplichte velden.
  7. De medewerker ontvangt een lijst met wijzigingen, met daarin de oorspronkelijke waarde en de voorgestelde waarde.
  8. Pas na menselijke goedkeuring stuurt de MCP-client de geldige tools/call-aanvraag naar de MCP-server.
  9. De tool, de wijziging, de release en het resultaat worden gedocumenteerd in het auditlogboek.

Foutgeval en reset

Als de MCP-server een foutmelding geeft of als een medewerker een onjuiste wijziging detecteert, wordt de publicatie stopgezet. Het concept blijft gescheiden van de laatst geldige openbare versie.

De verantwoordelijke redacteur corrigeert het concept of zet het terug naar de vorige versie. De foutstatus en de terugzetting worden geregistreerd. Tijd wordt bespaard door vooraf opgestelde zoekopdrachten, vergelijkingen en concepten – niet door ongecontroleerde publicaties.

Introduceer MCP-tools met minimale privileges.

Ik raad kleine bedrijven af ​​om direct volledige toegang te krijgen. Een beperkt pilotproject zal uitwijzen of de tool, de datakwaliteit en de verantwoordelijkheden goed aansluiten.

  1. Beperk de taak: Kies een duidelijk toepassingsvoorbeeld, zoals het vergelijken van twee taalversies.
  2. Begin met lezen: Sta in eerste instantie alleen het zoeken, ophalen en vergelijken van geselecteerde inhoud toe.
  3. Definieer het klantgebied: Beperk de test tot één website of inhoudsgebied.
  4. Resultaten controleren: Vergelijk de uitvoer van de tool met de daadwerkelijke brongegevens.
  5. Voeg specifiek schrijfrechten toe: Sta daarna alleen nog niet-openbare concepten toe.
  6. Testversie: Simuleer publicatie, afwijzing, fouten en terugdraaien.
  7. Controleer de machtigingen: Verwijder alle ongebruikte rollen en verlopen toegangsgegevens.

De praktische handleiding voor AI-richtlijnen in het mkb helpt u bij het reguleren van verantwoordelijkheden en toegestane gegevens, verder dan individuele toolaanroepen.

Statusinformatie in de MCP-toolcatalogus

  • Verkrijgbaar: De tool is geïmplementeerd in de gedocumenteerde versie, geactiveerd voor de klant en bruikbaar met de toegewezen rol.
  • Beperkte beschikbaarheid: Voor het gebruik van deze tool is aanvullende configuratie, een rechtenklasse of menselijke goedkeuring vereist.
  • disabled: De tool wordt niet aangeboden aan de betreffende klant of MCP-klant.
  • Voorbereide uitbreidingsfase: De architectuur biedt ruimte voor een toekomstige functionaliteit; momenteel is deze functionaliteit echter noch beschikbaar, noch toegezegd.

Een releasestatus zonder versienummer is onvolledig. Status, toolversie en releasedatum moeten altijd samen worden gedocumenteerd.

Selectiegids voor MCP-tools

Voordat u een tool activeert, moet u de volgende vragen beantwoorden:

  • doel: Welke specifieke operationele knelpunten lost de tool op?
  • Gegevens: Welke inhoud of persoonsgegevens kan de tool verwerken?
  • Cliënt: Voor welke gedefinieerde gegevensruimte geldt de toegang?
  • Rechtenklasse: Is lezen voldoende, of zijn er nog andere rechten vereist?
  • Externe invloed: Kan het verzoek publicatie-, communicatie-, export- of wijzigingsrechten verlenen?
  • Ophaalbaarheid: Kan een foutieve handeling volledig ongedaan worden gemaakt?
  • Vrijlating: Wie is verantwoordelijk?
  • Loggen: Welke informatie verschijnt in het auditlogboek?
  • Versiereferentie: Voor welk product en welke versie van het hulpmiddel is het proces getest?

Als een vraag onbeantwoord blijft, moet de tool gedeactiveerd blijven of in eerste instantie alleen met leesrechten in een testomgeving worden gebruikt. Daarom kijken we bij het adviseren over AI en digitalisering niet alleen naar de technische samenhang, maar ook naar het doel, de datakwaliteit, de verantwoordelijkheid en de omkeerbaarheid.

Vragen over de MCP-toolcatalogus van btlabs Core

Wat zijn MCP-tools?

MCP-tools zijn gestructureerde functies die een MCP-server aan een compatibele MCP-client aanbiedt. Een tool kan gegevens lezen, een ontwerp bewerken of een beperkt proces uitvoeren, mits de rol en de releasestatus de aanroep toestaan.

Wie voert technisch gezien een MCP-gesprek uit?

Het taalmodel kan het gebruik van een tool suggereren, maar voert de systeemactie niet zelf uit. De MCP-client dient de geldige aanroep in; de MCP-server voert de opgegeven tool uit.

Heeft tools/list al een machtiging?

Nee. `tools/list` toont de tools die de server retourneert voor de huidige context. Voor een specifieke `tools/call`-aanroep kunnen aanvullende privileges of menselijke goedkeuring vereist zijn.

Geeft tools/list altijd de volledige servercatalogus weer?

De MCP-specificatie maakt het mogelijk om de zichtbare reikwijdte te beperken op basis van autorisatie. Of een specifieke btlabs Core-installatie filtert op client en rol, moet worden bevestigd door een technische test op de gedocumenteerde einddatum.

Welke handelingen vereisen menselijke goedkeuring?

Publicaties, permanente verwijderingen, wijzigingen in rechten, gevoelige exporten, externe communicatie en systeemwijde interventies blijven onderworpen aan goedkeuring. De beslissing moet worden toegewezen aan een verantwoordelijke persoon en worden gedocumenteerd in het auditlogboek.

Hoe kan ik de huidige versie identificeren?

Een betrouwbare vermelding specificeert de productversie, de versie in de gereedschapscatalogus, de gereedschapsversie, de releasestatus en de ingangsdatum. Als deze informatie ontbreekt, is de vermelding geen betrouwbare, actuele productreferentie.

Wat gebeurt er als er een fout optreedt?

De MCP-server geeft een foutmelding; afhankelijke schrijf- of publicatiestappen worden gestopt. Omkeerbare wijzigingen worden door de verantwoordelijke rol teruggedraaid naar de laatst geldige status en vastgelegd.

Mag een agent zijn eigen rechten uitbreiden?

Nee. Een agent mag zijn bevoegdheidsklasse niet wijzigen en mag geen goedkeuringsstappen of klantgrenzen omzeilen. Wijzigingen in bevoegdheden vallen onder de beheerklasse en vereisen een aparte menselijke beslissing.

Waarom wordt er in het artikel geen vast aantal MCP-tools genoemd?

Een betrouwbaar aantal moet worden afgeleid uit de daadwerkelijke, versiespecifieke toolcatalogus. Zonder een geverifieerde serverexport zou een statisch aantal beschikbare, uitgeschakelde en voorbereide functies door elkaar halen.

Conclusie: MCP-tools vereisen geverifieerde machtigingen.

Een goede MCP-toolcatalogus documenteert niet alleen technische namen. De catalogus laat zien wie een tool mag gebruiken, voor welk doel, met welke gegevens, onder welke toegangsklasse en volgens welke vrijgaveregels.

Voor kleine bedrijven is gecontroleerde automatisering zinvoller dan onbeperkte autonomie. btlabs Core is ontworpen om de inspanningen voor zoeken, verifiëren en gegevensoverdracht te verminderen, terwijl ervoor wordt gezorgd dat gevoelige beslissingen bij de verantwoordelijke personen binnen het bedrijf blijven. Meer informatie vindt u op de pagina over AI-ready websites met btlabs Core.

Zwelling

  1. Specificatie van het Model Context Protocol: Architectuur — modelcontextprotocol.io (conceptstatus 2026-07-28)
  2. Specificatie van het Model Context Protocol: Hulpmiddelen — modelcontextprotocol.io (conceptstatus 2026-07-28)
Florian Berger
Blogrei.de