Lezen, een concept bewaren en publiceren zijn drie verschillende afspraken

Je geeft een assistent toegang tot je CMS om teksten klaar te zetten. Dat betekent nog niet dat hij ook bestaande artikelen mag overschrijven of nieuwe pagina’s openbaar mag maken. Toch verdwijnen die verschillen gemakkelijk achter één knop met een geruststellende naam, zoals beheer_content. Een bruikbare koppeling maakt niet alleen duidelijk wat een tool kan, maar ook wat deze gebruiker met dit specifieke artikel mag doen.

Beschrijf gevolgen, niet alleen toolnamen

MCP-tools hebben een naam en een invoerschema. Ze kunnen ook aanwijzingen meegeven over bijvoorbeeld alleen-lezen of mogelijk destructief gedrag. Zulke annotaties helpen een client bij presentatie en besluitvorming, maar zijn geen toegangscontrole. Een tool met een veilige naam kan nog steeds brede rechten gebruiken. De server moet de toegestane handeling zelf controleren; een instructie aan het model is daarvoor geen vervanging.

Een praktische scheiding bestaat uit drie beperkte acties: een artikel lezen, een concept bewaren en een goedgekeurd concept publiceren. Die namen hieronder zijn een ontwerpvoorbeeld, geen universele MCP-standaard. Niet iedere bestaande plugin biedt ze precies zo aan. Laat de bouwer daarom niet alleen een lijst beschikbare tools tonen, maar demonstreren welke acties technisch worden geweigerd.

• read_article: leest alleen toegestane inhoud en verandert niets. De invoer bevat een artikelidentifier en de bedoelde site, geen willekeurige databasequery.
• save_draft: maakt of wijzigt een concept binnen afgesproken secties. De tool kan niet via een extra invoerveld alsnog de publieke versie wijzigen.
• publish_draft: publiceert uitsluitend een specifiek concept met een gecontroleerde versie en geldige goedkeuring. Een algemene opdracht als “regel de content” is geen publicatiebewijs.

Een smalle tool op een brede sleutel is nog niet veilig

Onderliggende API-rechten tellen mee. De Craft GraphQL-documentatie vermeldt bijvoorbeeld dat draftmutaties geen afzonderlijke schemapermissie hebben die ze losmaakt van de bijbehorende canonieke entrymutaties. Alleen een tool draft noemen creëert die scheiding dus niet. Als de achterliggende toegang breder is, moet de koppeling de grens afdwingen, of moet je een andere technische route kiezen. Vraag expliciet waar die controle zit en hoe je haar test.

Leg voor iedere schrijfactie vast: wie vraagt dit, op welke site, in welke sectie, voor welk artikel en met welk effect? De server controleert die gegevens tegen de ingestelde rechten. Een concepttool hoort geen verborgen optie te accepteren waarmee de assistent een andere publicatiestatus of site kiest. Retourneer daarna een concrete identifier en status, zodat controle mogelijk is zonder op een mooi geformuleerd antwoord te vertrouwen.

Koppel akkoord aan de versie die is bekeken

INVOER
Een redacteur bekijkt concept 417, versie 7, voor de Nederlandse kennissectie. Hij geeft akkoord op die versie. Daarna verandert een collega de prijsvermelding: het concept is nu versie 8.

GEWENSTE UITKOMST
De publicatieactie voor versie 7 wordt geweigerd omdat het actuele concept is gewijzigd. De assistent toont het verschil en vraagt opnieuw om akkoord. Hij publiceert versie 8 niet op basis van het eerdere akkoord.

Een goedkeuring hoeft geen ingewikkeld scherm te zijn, maar moet wel ondubbelzinnig vastleggen wat de gebruiker heeft gezien. Laat titel, site, conceptversie en voorgenomen effect zien. Controleer vlak voor de schrijfactie opnieuw of de inhoud overeenkomt. Anders ontstaat een gat tussen “dit is akkoord” en “dit is gepubliceerd”. Bij wijzigingen van een collega is stoppen voor een nieuw akkoord correct gedrag, geen defect.

Test de grens vóór je de route vertrouwt

Gebruik een testomgeving of gecontroleerde concepten en leg vooraf de verwachte uitkomsten vast. Laat geweigerde acties geen echte publicaties of externe berichten veroorzaken. Hieronder staat een kleine acceptatieset. Dit zijn testontwerpen; ze bewijzen pas iets nadat iemand ze daadwerkelijk tegen de koppeling heeft uitgevoerd en de resultaten heeft vastgelegd.

1. Leesactie met een extra wijzigingsveld: de tool weigert de ongeldige invoer en de inhoud blijft identiek. Alleen het veld stilletjes negeren maakt fouten minder zichtbaar.
2. Concept opslaan voor een niet-toegestane site: de server weigert, ook als de assistent die site in zijn verzoek opneemt.
3. Geldig concept bewaren: er verschijnt precies één concept en de bestaande publieke pagina verandert niet. Lees beide toestanden terug.
4. Publiceren met verouderde goedkeuring: de actie stopt en meldt dat de actuele versie opnieuw bekeken moet worden.
5. Onduidelijk resultaat na een schrijfactie: de assistent controleert de status via identifier voordat hij opnieuw probeert. Een tweede publicatie of dubbel concept is geen acceptabele herstelstrategie.

Registreer minimaal actie, artikel- of conceptidentifier, gecontroleerde versie, uitkomst en tijd. Sla niet onnodig de hele artikelinhoud, sleutels of persoonsgegevens in het log op. Een gepubliceerd-statusveld is nuttig, maar sluit af met de publieke pagina teruglezen. Zo scheid je autorisatie, opslag en zichtbare publicatie: drie verschillende bewijzen voor drie verschillende vragen.

DOEL
Beoordeel mijn MCP-contenttools op afbakening. Voer geen tools uit en wijzig geen inhoud.

CONTEXT
Ik geef per tool de invoer, mogelijke effecten en server-side controles. Gewenste scheiding: lezen, concept bewaren en expliciet goedgekeurd publiceren. Een toolnaam of annotatie geldt niet als bewijs van afdwingbare rechten.

UITKOMST
Maak per tool een kort overzicht van toegestane effecten, mogelijke ongewenste effecten en ontbrekende controles. Ontwerp vijf veilige acceptatietests met invoer en verwachte uitkomst. Controleer afzonderlijk de sitegrens, conceptgrens, versiegebonden goedkeuring en afhandeling van onzekere schrijfacties. Noem niet-uitgevoerde tests ook niet geslaagd.

Je hoeft een assistent niet machteloos te maken om controle te houden. Je maakt zijn opdracht juist duidelijker: lezen waar dat mag, voorstellen bewaren waar dat nuttig is en publiceren wanneer de juiste versie daarvoor is vrijgegeven. Dat is een werkafspraak die zowel mensen als software kunnen controleren.