MCP in het SMM-paneel: je AI-assistent koppelen aan je account

MCP (Model Context Protocol) is een open protocol waarmee een AI-assistent de tools van een externe dienst rechtstreeks kan aanroepen, en in dit paneel betekent het concreet dat Claude, ChatGPT of een andere client diensten kan zoeken, prijzen kan berekenen en bestellingen kan plaatsen op jouw account, zonder dat je ooit je wachtwoord afgeeft. Je koppelt de assistent één keer via een goedkeuringsscherm in het paneel zelf, en daarna praat je gewoon: "wat kost 5.000 Instagram-volgers met aanvulling" of "hoe staat het met mijn bestellingen van gisteren".

Dit artikel legt uit hoe die koppeling werkt, wat er onder de motorkap gebeurt en waar de grenzen liggen. Niet als marketingverhaal, maar als handleiding: welke tools de assistent krijgt, in welke volgorde hij een bestelling moet plaatsen, welke rechten je kunt weghalen, hoe lang de tokens geldig zijn en welke foutmeldingen je gaat zien als er iets misgaat. Alles wat hieronder staat komt uit het paneel zelf; waar iets afhangt van de dienst die je kiest, zeg ik dat er expliciet bij.

Eén verwachting stel ik meteen bij, zodat de rest eerlijk blijft. Een gekoppelde AI-assistent maakt je niet slimmer in het kiezen van diensten en hij haalt geen betere resultaten uit een bestelling. Wat hij wel doet, is de saaie stukken wegnemen: zoeken in een catalogus met duizenden regels, prijzen uitrekenen voordat je klikt, twintig bestellingen tegelijk aanmaken, en achteraf de statussen samenvatten zonder dat je door je bestelgeschiedenis hoeft te scrollen. Dat is het verschil tussen een handige koppeling en een wondermiddel, en het is de moeite waard om dat verschil scherp te houden.

Wat is MCP en wat heb je eraan in een SMM-paneel?

MCP is een gestandaardiseerde manier waarop een AI-model tools van buitenaf kan gebruiken. In plaats van dat het model gokt wat een dienst kan, vraagt het bij het verbinden een lijst op: dit zijn de beschikbare tools, dit zijn hun namen, dit zijn de velden die ze verwachten en dit is wat ze teruggeven. Daarna roept het model die tools aan met echte parameters en krijgt het echte antwoorden terug. Er zit geen scherm tussen, geen browser die het model bestuurt en geen scraper die op een pagina-indeling vertrouwt.

Het verschil met een gewone API is klein maar belangrijk. Een API is bedoeld voor code die jij schrijft: jij leest de documentatie, jij bepaalt de volgorde van de aanroepen, jij vangt de fouten af. Een MCP-server is bedoeld voor een model dat de documentatie in de toollijst zelf meekrijgt. De beschrijving van elke tool vertelt niet alleen wat hij doet, maar ook wanneer hij aangeroepen hoort te worden en welke valkuil eronder zit. Daardoor kan een model dat het paneel niet kent er toch mee werken, mits het de instructies volgt.

Voor een SMM-paneel is dat om vier praktische redenen interessant. Ten eerste is de catalogus groot en zoeken erin is vervelend: een tool die op platform, categorie, prijsbereik en aanvullingsgarantie filtert, doet dat sneller dan jij met een zoekvak. Ten tweede is de prijsberekening foutgevoelig, en er is een tool die het bedrag uitrekent zonder de bestelling te plaatsen. Ten derde is bulk werk waar mensen fouten in maken. En ten vierde is statuscontrole pure routine: een model kan zeven bestellingen doorlopen en alleen de twee eruit lichten die vastzitten.

Wat het niet is: een garantie op betere resultaten of een manier om goedkoper te bestellen. De prijzen die de assistent ziet zijn exact jouw prijzen uit het paneel, met dezelfde marges en dezelfde persoonlijke prijsfactor. De catalogus is dezelfde catalogus die je op de openbare dienstenpagina ziet. Er zit geen aparte AI-korting achter en er zit ook geen extra kostenpost aan de koppeling zelf.

Voor wie is deze koppeling bedoeld, en voor wie niet?

Deze koppeling is bedoeld voor iedereen die vaker dan af en toe bestelt en die al met een AI-assistent werkt. Concreet: bureaus die voor meerdere klanten inkopen, resellers die dagelijks dezelfde routine draaien, en mensen die liever een vraag stellen dan door menu's klikken. Als je één keer per maand een bestelling plaatst, levert het je vooral een leuke demo op en weinig tijdwinst.

Er is een tweede groep waarvoor het duidelijk waarde heeft: mensen die willen automatiseren maar geen zin hebben in een integratieproject. De ontwikkelaars-API vraagt om code, om foutafhandeling en om een plek waar die code draait. Een MCP-koppeling vraagt om één adres in je client plakken. Je krijgt daarmee niet dezelfde betrouwbaarheid als een goed geschreven integratie, want er zit een model tussen dat kan afwijken, maar je krijgt wel binnen vijf minuten iets werkends.

Voor wie is het niet bedoeld? Voor onbewaakte automatisering. Er zit geen mechanisme in dat de assistent zelfstandig laat bestellen op basis van een schema. De serverinstructie draagt het model expliciet op om vóór het plaatsen van een bestelling om jouw akkoord te vragen, en dat akkoord is een menselijke handeling. Wil je echt onbewaakt draaien, dan is de gewone API met je eigen code de juiste weg, en die staat beschreven op de pagina met API-documentatie.

En het is niet bedoeld als vervanging van het paneel. Er zijn dingen die alleen in het paneel kunnen: saldo opwaarderen, een supportticket openen, je wachtwoord wijzigen, tweestapsverificatie instellen. De assistent heeft geen tool voor die dingen en krijgt die ook niet. Hoe het paneel zelf werkt, van registratie tot bestelling, staat in de complete handleiding voor het paneel.

Het paneel heeft twee aparte MCP-servers: welke is voor wie?

Er draaien twee MCP-servers naast elkaar, en het is nuttig om het verschil te kennen voordat je aan de slag gaat, al is er maar één die jou als klant aangaat. De ene bedient klanten en werkt op één account tegelijk. De andere bedient de paneeleigenaar en kan het hele paneel besturen.

	Klantserver	Beheerserver
Adres	POST /api/mcp/user	POST /api/mcp
Wie koppelt	de klant van het paneel	de eigenaar van het paneel
Identificatie	OAuth 2.1-token of de API-sleutel van het account	één geheime sleutel (MCP_SECRET)
Bereik	alleen het eigen account, 18 tools	het hele paneel, 57 tools
Logboek	aiAuditLog met accountnummer	aiAuditLog zonder accountnummer

Beide servers gebruiken dezelfde kern, dus het protocolgedrag is identiek: dezelfde methoden, dezelfde foutafhandeling, dezelfde logging. Wat verschilt is de sleutelbos. De klantserver is vastgeklonken aan het account waarmee je hebt gekoppeld en kan er niet omheen: er is geen parameter waarmee je een ander accountnummer meegeeft, geen tool die andermans bestellingen laat zien en geen tool die prijzen of diensten wijzigt.

Voor de rest van dit artikel gaat het over de klantserver, tenzij ik expliciet iets anders zeg. Het adres dat je nodig hebt is https://panelfollows.com/api/mcp/user, en je vindt het ook op de paneelpagina die hieronder aan bod komt. Ben je klant van een subpanel, dan is jouw adres het domein van dat subpanel met hetzelfde pad erachter.

Hoe praat een AI-client eigenlijk met het paneel?

De verbinding is gewoon HTTP. De client stuurt een POST-verzoek met een JSON-RPC 2.0-bericht in de body en krijgt een JSON-antwoord terug. Er is geen websocket, geen langlopende verbinding en geen sessie die op de server wordt bijgehouden. Elk verzoek staat op zichzelf en draagt zijn eigen identificatie mee. Dat maakt de koppeling saai in de goede zin: er is niets dat kan "vastlopen" tussen twee aanroepen door.

Er is één ding dat verrast als je het niet weet: er is geen SSE-stroom. Sommige MCP-clients proberen na het verbinden een GET-verzoek op hetzelfde adres om een gebeurtenisstroom te openen. Dat verzoek levert hier HTTP 405 op, met de melding dat SSE niet ondersteund wordt en dat je POST moet gebruiken voor JSON-RPC. Zie je in de logs van je client een 405 langskomen, dan is dat dus geen storing maar het verwachte antwoord, en de POST-kant werkt daarnaast gewoon.

Methode	Wat hij doet
initialize	Onderhandelt de protocolversie en meldt wat de server kan
tools/list	Geeft de lijst met beschikbare tools, inclusief hun velden en hints
tools/call	Roept één tool aan met parameters
prompts/list	Geeft de kant-en-klare commando's
prompts/get	Haalt de tekst van één commando op, met jouw argumenten ingevuld
ping	Levensteken
resources/list	Bestaat, maar geeft een lege lijst terug
resources/templates/list	Bestaat, maar geeft een lege lijst terug

De eigen protocolversie is 2025-06-18. Oudere clients worden niet weggestuurd: 2025-03-26 en 2024-11-05 worden ook geaccepteerd, en welke versie er gebruikt wordt, spreken client en server tijdens initialize samen af. JSON-RPC-batches worden ondersteund, dus een client mag meerdere berichten in één array sturen. Bevat zo'n verzoek alleen notificaties, dan komt er HTTP 202 terug zonder body, precies zoals de specificatie voorschrijft.

Twee details die je terugziet in het gedrag van je assistent. Een fout in een tool is geen protocolfout: je krijgt gewoon een geslaagd antwoord terug waarin isError: true staat, met de foutmelding als leesbare tekst. Dat is bewust, want zo kan het model de fout lezen en zichzelf corrigeren in plaats van de verbinding te verbreken. En de uitvoer van een tool wordt afgekapt bij 100.000 tekens, zodat één te brede zoekopdracht niet het hele contextvenster van je model opslokt.

Tot slot krijgt elke tool in het antwoord van tools/list twee hints mee: of hij alleen leest en of hij destructief is. Clients gebruiken die hints om te bepalen of ze je om bevestiging vragen. Een tool die alleen leest, mag een client zonder vragen uitvoeren; een tool die geld uitgeeft, hoort een bevestigingsdialoog te krijgen. Hoe streng je client daarmee omgaat, bepaalt de client zelf, dus reken er niet blind op.

Welke 18 tools krijgt je assistent?

De assistent krijgt achttien tools, verdeeld over vijf gebieden. Twaalf ervan lezen alleen, zes schrijven. De namen staan hieronder letterlijk zoals ze in de toollijst verschijnen, zodat je ze herkent als je client ze laat zien.

Gebied	Tools
Account	get_account
Catalogus	list_platforms, list_categories, search_services, get_service
Bestellingen	preview_order, create_order, create_orders_bulk, list_orders, get_order, cancel_order, refill_order
Aanvulling	list_refills, get_refill
Automatisering	list_events, list_webhooks, create_webhook, delete_webhook

De twaalf leestools zijn get_account, list_platforms, list_categories, search_services, get_service, preview_order, list_orders, get_order, list_refills, get_refill, list_events en list_webhooks. De zes schrijftools zijn create_order, create_orders_bulk, cancel_order, refill_order, create_webhook en delete_webhook. Binnen die zes zijn er vier als destructief gemarkeerd: create_order, create_orders_bulk, cancel_order en delete_webhook. De andere twee, refill_order en create_webhook, schrijven wel maar richten geen schade aan.

Een paar tools verdienen een toelichting, omdat je gedrag ervan in gesprekken terugziet.

• get_account geeft je accountnummer, je e-mailadres, je beschikbare saldo in dollars en je verzoeklimiet. Dit is de tool die de assistent hoort te gebruiken voordat hij zegt of iets past.
• search_services filtert op search, platform, category, type, refill, cancel, dripfeed, min_rate en max_rate. De paginagrootte is standaard 20 en maximaal 50, bewust klein gehouden omdat elk resultaat als tekst in het contextvenster van het model belandt.
• get_service geeft de prijs, de min- en maxgrenzen, of aanvulling, annulering en drip feed ondersteund worden, de gemiddelde doorlooptijd en, belangrijk, de lijst met bestelvelden (fields). Daarmee hoeft het model niet te gokken welke velden verplicht zijn.
• preview_order valideert een bestelling zonder hem te plaatsen en geeft charge, balance_after en sufficient_balance terug. Dit is de belangrijkste tool van de hele set, want hij maakt het verschil tussen "ik denk dat het ongeveer zoveel kost" en een exact bedrag.
• create_order geeft echt geld uit en is niet terug te draaien.
• create_orders_bulk neemt maximaal 50 bestellingen per aanroep. De regels worden op volgorde verwerkt en een mislukte regel stopt de rest niet: elke regel krijgt zijn eigen resultaat terug.
• list_orders filtert op status (pending, in_progress, completed, partial, canceled, refunded, failed), standaard 20 en maximaal 100 records per pagina.
• cancel_order werkt alleen als de dienst annulering ondersteunt en de bestelling nog niet is afgerond. Kan het niet, dan krijg je cancel_not_supported terug en is een supportticket de weg.
• refill_order werkt alleen bij afgeronde bestellingen op een dienst met aanvullingsgarantie. Het kost niets en raakt je saldo niet.
• create_webhook toont het ondertekeningsgeheim één keer in het antwoord. Daarna is het niet meer op te vragen.
• delete_webhook verwijdert het adres en laat ook de wachtende bezorgingen vallen.

Alle lijsttools werken met een cursor: je geeft starting_after mee en krijgt in het antwoord een next_cursor terug voor de volgende pagina. Dat is dezelfde manier van pagineren als in de gewone API, en dat is geen toeval, want elke tool is een spiegel van een endpoint uit die API. De parameternamen zijn letterlijk gelijk: service, link, quantity, runs, interval, comments, username, posts, min, max, usernames, hashtag, hashtags, answer_number, groups, keywords en media. Wat in de documentatie staat, geldt dus ook hier, en je hoeft geen tweede woordenlijst te leren.

Hoe koppel je je AI-assistent aan het paneel?

Koppelen kost drie handelingen en geen enkele daarvan is het kopiëren van een sleutel. De pagina waar je begint heet "Koppel je AI-assistent" en staat in het menu van je dashboard onder "AI-assistent", op de MCP-pagina in je dashboard.

1. Kopieer het verbindingsadres. Bovenaan staat het blok "Verbindingsadres" met daaronder het adres en een knop "Kopiëren". De uitleg eronder zegt precies waar het om draait: je geeft toestemming hier in het paneel en je wachtwoord wordt nooit met de client gedeeld.
2. Voeg het adres toe als MCP-server in je client. Hoe dat gaat, hangt van je client af; onder "Installatie per client" staan kant-en-klare voorbeelden die je kunt kopiëren.
3. Keur de koppeling goed. Je client stuurt je naar het paneel, je ziet een goedkeuringsscherm en daar zet je desgewenst het vinkje voor alleen-lezen. Daarna ben je klaar en kun je gewoon praten: "laat prijzen voor Instagram-volgers zien" of "hoe staat het met mijn laatste bestellingen".

Voor Claude Code is de opdracht één regel:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user

Voor clients die met een configuratiebestand werken, zoals Cursor of VS Code, is het een klein blokje JSON:

{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }

Bij de eerste aanroep krijgt je client een 401 terug en start hij vanzelf de goedkeuringsflow. Je browser opent, je logt in als je nog niet ingelogd bent, je ziet het goedkeuringsscherm en na je klik ben je terug in je client. Vanaf dat moment ververst de client zijn toegang zelf en hoef je er niet meer naar om te kijken.

Er staat op de pagina één zin die je serieus moet nemen: elke MCP-client die OAuth 2.1 spreekt, werkt. Er is geen lijst met goedgekeurde merken en er wordt niet op naam gefilterd. Kan je client streamable HTTP en OAuth met PKCE, dan kan hij koppelen. Kan je client alleen een vaste header meesturen, dan is er de sleutelroute, en die komt verderop aan bod.

Wat doet de OAuth 2.1-flow precies op de achtergrond?

Het goedkeuringsscherm is de zichtbare helft van een standaardflow die uit zes stappen bestaat. Je hoeft er niets van te weten om te koppelen, maar als er iets misgaat, weet je met deze kennis binnen een minuut waar het hangt.

1. De client probeert het zonder identificatie en krijgt een 401 terug. In dat antwoord zit een WWW-Authenticate-header met een verwijzing naar het metadatadocument van de beschermde bron, volgens RFC 9728.
2. De client volgt die verwijzing. Eerst /.well-known/oauth-protected-resource, dat vertelt welke autorisatieserver erbij hoort. Daarna /.well-known/oauth-authorization-server, het ontdekkingsdocument volgens RFC 8414, met alle adressen die de client nodig heeft.
3. De client registreert zichzelf met een POST naar /api/mcp/oauth/register, dynamische clientregistratie volgens RFC 7591. Er wordt een client zonder geheim aangemaakt: de identificatie gebeurt met PKCE en niet met een wachtwoord. Registratie is beperkt tot tien pogingen per uur per IP-adres.
4. Je browser opent op /api/mcp/oauth/authorize, dat je doorstuurt naar het goedkeuringsscherm van het paneel op het adres /mcp/connect. Ben je niet ingelogd, dan ga je eerst langs de inlogpagina en kom je daarna op precies datzelfde scherm terug.
5. Je keurt goed. Wil je de assistent alleen laten kijken, dan zet je hier het vinkje "Alleen-lezen toegang geven (kan geen bestellingen plaatsen)".
6. De client wisselt de code in voor een token met een POST naar /api/mcp/oauth/token. Hierbij is PKCE met S256 verplicht; de variant plain wordt geweigerd, want dat is de regel van OAuth 2.1.

Het ontdekkingsdocument is expliciet over wat er wel en niet mag: response_types_supported bevat alleen code, grant_types_supported bevat authorization_code en refresh_token, token_endpoint_auth_methods_supported staat op none (public client), en code_challenge_methods_supported bevat alleen S256. Daarnaast staat authorization_response_iss_parameter_supported aan (RFC 9207), zodat een client die met meerdere autorisatieservers praat niet in de war kan raken over waar een code vandaan kwam, en resource_indicators_supported (RFC 8707), zodat een client kan zeggen voor welke bron hij het token wil.

Twee dingen over adressen. De teruggaveadressen die een client registreert, mogen https zijn, een lokaal adres over http (127.0.0.1 of localhost) of een eigen schema zoals cursor:// of vscode://. Gewoon http naar een adres op internet wordt geweigerd. En bij het inwisselen moet het teruggaveadres overeenkomen met wat er geregistreerd is; de enige speling zit in het poortnummer van een lokaal adres, zoals RFC 8252 voorschrijft, omdat desktopclients bij elke start een vrije poort pakken.

Nog een detail dat vooral voor subpanelen telt: alle adressen worden opgebouwd uit de oorsprong van het verzoek zelf. Koppelt een klant van een subpanel vanaf zijn eigen domein, dan is de uitgever van de tokens dat domein, en het adres van het hoofdpaneel komt nergens in beeld. Voor een white-label paneel is dat het verschil tussen een nette koppeling en een lek in je merk.

Intrekken kan van twee kanten: de client kan een POST doen naar /api/mcp/oauth/revoke, en jij kunt in het paneel met één klik de koppeling verbreken. Dat laatste komt verderop aan bod, bij het onderdeel over gekoppelde assistenten.

Wanneer is koppelen met een API-sleutel logischer?

Naast OAuth is er een tweede route: je stuurt een sleutel mee als header en slaat de hele browserflow over. Dat is bedoeld voor clients die geen OAuth spreken maar wel een vaste header kunnen meesturen, en voor scripts waarin een browser openen geen optie is.

De server accepteert drie soorten waarden in de Authorization: Bearer-header: een OAuth-token dat begint met pf_mcp_, een API-sleutel van de ontwikkelaars-API die begint met pf_live_, en de oudere resellersleutel van 64 hexadecimale tekens. De header X-Api-Key wordt ook geaccepteerd. Welke route er gebruikt wordt, leidt de server puur af uit het voorvoegsel van de waarde, dus er is geen extra veld waarin je iets moet aangeven.

Voor Claude Code ziet dat er zo uit:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
  --header "Authorization: Bearer pf_live_..."

En als je alleen wilt controleren of de verbinding staat, is één curl-aanroep genoeg. De toollijst opvragen kost niets en verandert niets:

curl -s https://panelfollows.com/api/mcp/user \
  -H "Authorization: Bearer pf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Er is één verschil dat je moet kennen voordat je hiervoor kiest. Een verbinding met een sleutel is altijd volledig bevoegd. De beperking tot alleen-lezen bestaat alleen in de OAuth-route, want dat is een eigenschap van het token en niet van het account. Wil je een assistent die echt niets kan bestellen, dan is OAuth met het vinkje voor alleen-lezen de enige manier om dat af te dwingen.

	OAuth 2.1	API-sleutel
Wat je invoert	alleen het adres	het adres plus een header met de sleutel
Waar de goedkeuring staat	goedkeuringsscherm in het paneel	nergens, de sleutel is de goedkeuring
Alleen-lezen mogelijk	ja, met een vinkje	nee, altijd volledige toegang
Zichtbaar in "Gekoppelde assistenten"	ja	nee
Intrekken	per koppeling, met één klik	door de sleutel opnieuw te genereren
Geschikt voor	desktopclients en chatapps	scripts, servers, clients zonder OAuth

De praktische vuistregel: gebruik OAuth voor alles waar een mens bij zit, en een sleutel voor alles wat op een server draait. Een sleutel aanmaken doe je op de API-pagina in je dashboard, en de pagina met de MCP-koppeling verwijst daar zelf ook naar met de tekst "Liever koppelen met een sleutel? Maak er hier een aan". Behandel zo'n sleutel als een wachtwoord, want hij geeft toegang tot je saldo.

Wat zie je op het goedkeuringsscherm en waar zeg je precies ja tegen?

Het goedkeuringsscherm staat op het adres /mcp/connect en is de enige plek waar de koppeling ontstaat. Je komt er alleen terecht als een client de flow gestart heeft; het scherm rechtstreeks openen levert niets op, want er is dan geen verzoek om goed te keuren.

Bovenaan staat de kop met de naam van de client die om toegang vraagt, in de vorm "{naam} wil koppelen met je account", gevolgd door de zin "Als je goedkeurt, mag deze app het volgende namens jou doen." Daaronder staan drie feiten waar je even naar moet kijken voordat je klikt:

• "Account": het e-mailadres van het account waarvoor de koppeling gaat gelden. Heb je meerdere accounts, dan is dit de plek waar je merkt dat je in het verkeerde bent ingelogd.
• "Stuurt je door naar": het adres waar je na goedkeuring naartoe gaat. Bij een lokale client is dat een adres op 127.0.0.1 met een poortnummer, bij een desktopclient meestal een eigen schema. Ziet dit er onverwacht uit, keur dan niet goed.
• De lijst met rechten die de client vraagt.

Daaronder staat het vinkje "Alleen-lezen toegang geven (kan geen bestellingen plaatsen)" en twee knoppen: "Koppeling goedkeuren" en "Weigeren". Na je klik zie je kort "Bezig met doorsturen…" en daarna ben je terug in je client.

Wachtte je te lang, dan krijg je de melding "Dit koppelingsverzoek is ongeldig of verlopen. Begin opnieuw vanuit je client." Dat is geen storing: de autorisatiecode is tien minuten geldig en eenmalig. Start de flow gewoon opnieuw vanuit je client en het lukt wel.

Twee dingen die dit scherm nadrukkelijk niet doet. Het vraagt niet om je wachtwoord, want je bent al ingelogd in het paneel en de client komt daar nooit bij. En het geeft geen sleutel aan de client die je zelf moet doorgeven; de uitwisseling gebeurt op de achtergrond tussen client en server. Zou een pagina die op dit scherm lijkt je om je wachtwoord vragen, dan is dat niet dit paneel.

Wat schakelt "Alleen-lezen" precies uit?

Alleen-lezen is geen instructie aan het model maar een harde beperking van de toollijst. Kies je die optie, dan krijgt het token uitsluitend het recht account:read, en de server geeft die verbinding een gefilterde toollijst: de zes schrijftools staan er simpelweg niet in. Het model kan create_order niet verkeerd gebruiken, want het weet niet dat die tool bestaat.

Dat verschil is belangrijk genoeg om even bij stil te staan. Je zou een schrijftool ook kunnen tonen en hem bij aanroep weigeren. Dan hangt de veiligheid van je account af van de vraag of het model zich aan een instructie houdt, en dat is geen fundering waar je op wilt bouwen. Door de tool helemaal niet te tonen, is er niets om aan te roepen. Daarnaast krijgt het model in zijn serverinstructie een extra zin mee waarin staat dat deze verbinding alleen-lezen is en dat jij het vinkje in het paneel moet weghalen als je toch wilt bestellen.

Wat de assistent kan	Volledige toegang	Alleen-lezen
Diensten zoeken en vergelijken	ja	ja
Prijs berekenen met preview_order	ja	ja
Saldo en bestellingen bekijken	ja	ja
Aanvullingen en gebeurtenissen bekijken	ja	ja
Bestelling plaatsen	ja	tool niet aanwezig
Bulkbestelling plaatsen	ja	tool niet aanwezig
Bestelling annuleren	ja	tool niet aanwezig
Aanvulling aanvragen	ja	tool niet aanwezig
Webhook aanmaken of verwijderen	ja	tool niet aanwezig

Let op dat preview_order bij alleen-lezen gewoon beschikbaar blijft. Dat is met opzet: prijzen uitrekenen is de nuttigste functie van de hele set en hij geeft geen geld uit. Je kunt dus prima een assistent koppelen die je alleen mag adviseren, en zelf in het paneel op "Bestelling plaatsen" klikken als je akkoord bent.

Er zijn twee rechten in totaal: account:read en account:write. Vraagt een client niets specifieks, dan krijgt hij ze allebei. Vraagt hij rechten die hier niet bestaan, zoals openid, profile of email, dan worden die stilletjes genegeerd in plaats van dat de flow crasht. En de badge die je later in het paneel bij de koppeling ziet staan, is precies deze keuze: "Volledige toegang" of "Alleen-lezen".

In welke volgorde plaatst de assistent een bestelling?

De server geeft het model een vaste volgorde mee, en die volgorde is er niet voor de sier: de derde stap is de stap waar geld verkeerd kan gaan. Zo hoort het te lopen.

1. Zoeken. Met search_services wordt een passende dienst gevonden en het dienstnummer genoteerd.
2. Detail lezen. Met get_service worden de min- en maxgrenzen, de ondersteuning voor aanvulling en annulering, de gemiddelde doorlooptijd en de verplichte bestelvelden opgehaald.
3. Prijs berekenen. Met preview_order wordt het bedrag uitgerekend. De velden charge en sufficient_balance hoort de assistent onverkort aan je door te geven.
4. Jouw akkoord vragen. Zonder expliciete bevestiging hoort er niet besteld te worden, want een bestelling geeft echt geld uit en is niet terug te draaien.
5. Bestellen. Met create_order wordt de bestelling geplaatst en het bestelnummer aan jou teruggegeven.

In de praktijk ziet zo'n gesprek er ongeveer zo uit. Jij zegt: "ik wil ongeveer vijfduizend Instagram-volgers met aanvullingsgarantie, wat zijn mijn opties." De assistent zoekt, vergelijkt een handvol diensten op prijs, grenzen, garantie en doorlooptijd, en zet ze naast elkaar. Jij kiest er een. De assistent rekent het bedrag uit en zegt wat er van je saldo af gaat en wat er daarna overblijft. Jij zegt ja. Pas dan wordt de bestelling geplaatst en krijg je het nummer terug.

Waar het misgaat als een stap wordt overgeslagen: zonder get_service weet het model niet welke velden verplicht zijn en verzint het er een, met een geweigerde bestelling als gevolg. Zonder preview_order noemt het model een bedrag dat het zelf heeft uitgerekend, en dat kan er duizend keer naast zitten. Merk je dat je assistent zomaar een bedrag noemt zonder eerst iets op te vragen, vraag hem dan om het na te rekenen met de voorbeeldtool. Dat kost één aanroep en het scheelt teleurstelling.

De assistent krijgt daarnaast expliciet mee dat bedragen in dollars zijn en als decimale tekst terugkomen, niet als getal. Dat klinkt als een technisch detail, maar het voorkomt dat een model een bedrag door een afronding haalt en er iets anders uit laat komen dan wat er straks werkelijk wordt afgeschreven.

Waarom een prijs duizend keer verkeerd kan uitvallen

Dit is de belangrijkste valkuil in het hele artikel, en hij zit in het antwoord van search_services en get_service verstopt in één veld: pricing.unit.

Staat er per_1000, dan is de prijs die je ziet de prijs voor duizend stuks. Dat is het normale geval en de rekensom is tarief gedeeld door duizend, maal je aantal. Staat er per_order, dan is de prijs die je ziet de prijs van de hele bestelling, ongeacht het aantal. Dat is het geval bij pakketdiensten. Wie dat veld negeert en overal door duizend deelt, komt bij een pakketdienst een factor duizend te laag uit.

Waarde van pricing.unit	Wat de prijs betekent	Rekensom
per_1000	prijs voor 1.000 stuks	tarief / 1000 × aantal
per_1000 met drip feed	prijs voor 1.000 stuks	tarief / 1000 × aantal per ronde × rondes
per_order	prijs van het hele pakket	het tarief, één keer

De beschrijving van search_services waarschuwt het model hier expliciet voor, en de serverinstructie herhaalt het nog een keer. Toch is de betrouwbare oplossing niet "hopen dat het model oplet" maar preview_order gebruiken. Die tool rekent aan de serverkant, met dezelfde code die de echte bestelling gebruikt, en geeft één bedrag terug. Er valt niets aan te interpreteren.

Praktisch advies: laat je assistent bij een dienst die je nog niet kent altijd eerst een voorbeeld maken van een klein aantal. Zie je dat het bedrag ongeveer klopt met wat je verwachtte, dan kun je opschalen. Zie je een bedrag dat er wild naast zit, dan kijk je naar pricing.unit en naar de min- en maxgrenzen van de dienst voordat je verder gaat. Ook in het paneel zelf zit dezelfde valkuil, en die wordt uitgelegd in de handleiding over het paneel.

Hoe werken bulk, drip feed en speciale diensttypen via de assistent?

Bulk werkt via één tool, create_orders_bulk, met maximaal vijftig bestellingen per aanroep. Elke regel bevat dezelfde velden als een gewone bestelling. De regels worden op volgorde verwerkt en een fout in regel drie stopt regel vier niet: je krijgt per regel een eigen resultaat terug, zodat je precies ziet welke gelukt zijn en welke niet.

Dat gedrag maakt bulk bruikbaar maar vraagt om discipline. Er is geen totaalbedrag dat je vooraf te zien krijgt, dus de enige manier om te weten wat vijftig regels gaan kosten, is elke regel eerst door preview_order halen. Voor tien regels is dat prima; voor vijftig regels is het slim om je assistent te vragen de bedragen in een tabel te zetten en op te tellen voordat je akkoord geeft. Wat je bespaart aan tijd, verlies je anders aan een verrassing.

Drip feed gaat via de velden runs en interval, precies zoals in de gewone API. Het aantal dat je opgeeft is het aantal per ronde, niet je totaal. Bestel je duizend stuks over tien rondes, dan bestel je tienduizend stuks en betaal je daarvoor. En drip feed werkt alleen bij diensten die het ondersteunen; of dat zo is, lees je uit get_service. Wat gespreide levering wel en niet oplost, staat in de gids over drip feed en automatische diensten.

Speciale diensttypen hebben elk hun eigen extra velden. De assistent hoort ze niet te raden maar uit de fields-lijst van get_service te halen. Ter oriëntatie de belangrijkste:

Veld	Waarvoor	Hoe het telt
comments	eigen reacties	één reactie per regel, het aantal regels is het aantal
username	abonnementsdiensten en typen die een naam vragen	niet van toepassing
posts, min, max	abonnementsdiensten (auto views, auto likes)	max per post × aantal posts
usernames	vermeldingen uit een eigen lijst	één naam per regel
hashtag en hashtags	vermeldingen op basis van een hashtag	één per regel bij meerdere
answer_number	polls	het volgnummer van de optie
groups	groepsuitnodigingen	één groepslink per regel
keywords	SEO-diensten	één zoekwoord per regel
media	typen die een medialink vragen	niet van toepassing

De belangrijkste regel bij reactietypen: stuur geen quantity mee. Het aantal wordt bepaald door het aantal regels dat je in comments zet. Doe je het toch, dan klopt de berekening niet met wat je verwacht. De serverinstructie zegt dit ook letterlijk tegen het model, maar het is handig als jij het ook weet, want dan herken je meteen wat er misging.

Wat kan de assistent niet doen?

Dit is de lijst waar je het snelst duidelijkheid uit haalt, en hij is bewust kort. De grenzen zitten niet in een instructie maar in het feit dat de tools er niet zijn.

• Saldo opwaarderen. Er is geen betaal-tool. Opwaarderen doe je zelf in het paneel.
• Geld opnemen. Bestaat niet als functie en dus ook niet als tool.
• Prijzen wijzigen. De prijzen die de assistent ziet zijn jouw prijzen; hij kan er niets aan veranderen.
• Een supportticket openen. Er is geen tool voor. Wil je hulp van een mens, dan open je zelf een ticket in het paneel.
• Bij andere accounts komen. De verbinding is aan één account gekoppeld en er is geen parameter die dat verandert.
• Je wachtwoord zien of wijzigen. De client krijgt je wachtwoord nooit te zien, ook niet tijdens het koppelen.
• Tweestapsverificatie aan- of uitzetten. Beveiligingsinstellingen zitten volledig buiten deze set.

De paneelpagina vat het in drie zinnen samen die je precies zo terugziet in de sectie "Wat de assistent kan doen": hij zoekt diensten, berekent prijzen en bekijkt je bestellingen en saldo; hij plaatst, annuleert en vult aan en vraagt vóór het plaatsen je bevestiging; en hij kan geen saldo opwaarderen, geen geld opnemen, je wachtwoord niet zien en niet bij andere accounts.

Nog twee grenzen die minder voor de hand liggen. De assistent kan geen aanvulling afdwingen bij een dienst die geen aanvullingsgarantie heeft, want dan bestaat die mogelijkheid niet aan de kant van de uitvoerende partij. En hij kan een bestelling niet annuleren bij een dienst die annuleren niet ondersteunt: dan komt cancel_not_supported terug en is een ticket de enige weg. Waarom aanvulling niet altijd bestaat en wat je er wel en niet van mag verwachten, staat in het artikel over uitval en aanvulling.

Beveiliging: je wachtwoord, de tokens en hun looptijden

Het uitgangspunt van de hele koppeling is dat je wachtwoord het paneel niet verlaat. Je client krijgt een token, geen wachtwoord, en dat token heeft een beperkte levensduur en een beperkt bereik. Hieronder staan alle geheimen die in deze flow voorkomen, met hun voorvoegsel en hun geldigheid.

Geheim	Voorvoegsel	Geldig
Autorisatiecode	pf_mca_	10 minuten, eenmalig
Toegangstoken	pf_mcp_	8 uur
Vernieuwingstoken	pf_mcr_	90 dagen, wisselt bij elk gebruik
Client-id	mcpc_	onbeperkt
API-sleutel	pf_live_	tot je hem intrekt

Alle waarden zijn 32 bytes willekeurigheid (256 bits), gecodeerd als base64url. In de database staat alleen een HMAC-SHA256-afdruk; de leesbare waarde wordt nergens bewaard. De sleutel waarmee die afdruk wordt gemaakt, komt uit de serverconfiguratie en niet uit de database, zodat een gelekte databasedump op zichzelf geen bruikbare tokens oplevert.

Er zit één beveiliging in die je moet kennen omdat je hem kunt merken. Wordt een autorisatiecode een tweede keer gebruikt, of komt er een vernieuwingstoken binnen dat al is ingetrokken, dan worden alle tokens van die client voor jouw account ingetrokken. Dat is de standaardreactie op een mogelijk gestolen code: liever een keer opnieuw koppelen dan doorgaan terwijl er misschien iemand meekijkt. Zie je dat een client die het altijd deed ineens opnieuw om goedkeuring vraagt, dan is dit vaak de verklaring.

Praktische adviezen die het meeste opleveren. Zet tweestapsverificatie aan op je paneelaccount, want de koppeling begint met een ingelogde sessie en die sessie is de zwakste schakel. Keur nooit een koppelingsverzoek goed waarvan je het teruggaveadres niet herkent. En verbreek koppelingen die je niet meer gebruikt, want een token dat niemand gebruikt is alleen maar een openstaande deur.

Wat houdt het logboek van elke aanroep bij?

Elke toolaanroep wordt vastgelegd. Dat is geen bijzaak maar de reden waarom je een gekoppelde assistent überhaupt kunt vertrouwen: achteraf is er altijd te herleiden wat er is gebeurd, door welke client en met welke gegevens.

Wat er per aanroep in het logboek komt: de client (herkend aan de user agent), het accountnummer, de naam van de tool, de meegegeven parameters, het resultaat, een eventuele fout en hoe lang de aanroep duurde. Omdat de klantserver het accountnummer invult en de beheerserver dat veld leeg laat, is in hetzelfde logboek te zien welke aanroepen van een klant kwamen en welke van de paneelbeheerder.

Er zitten drie beperkingen in die het logboek bruikbaar houden in plaats van dat het volloopt.

• Geheimen worden gemaskeerd. Parameters die eruitzien als een geheim, zoals apikey, api_key, secret, password, passphrase en token, worden vervangen door sterretjes. Er komt dus geen sleutel in het logboek terecht, ook niet per ongeluk.
• Resultaten van leestools worden niet opgeslagen. Een zoekopdracht die vijftig diensten teruggeeft, levert veel tekst en weinig inzicht op. Van schrijftools wordt het resultaat wel bewaard, want dat is precies het bewijs dat je later nodig hebt.
• Parameters en resultaten worden afgekapt bij 8.000 tekens. Een bulkbestelling van vijftig regels blijft daarmee leesbaar zonder de opslag op te blazen.

Het praktische gevolg voor jou: van een bestelling is later te zien of hij via de assistent of via het paneel is geplaatst. Bij een discussie over "ik heb dat nooit besteld" is dat een concreet aanknopingspunt in plaats van een welles-nietes.

Nog een detail dat over betrouwbaarheid gaat: het schrijven van het logboek is best effort. Lukt het niet, dan gaat de aanroep gewoon door. Dat is de juiste keuze, want een bestelling die mislukt omdat een logregel niet weggeschreven kon worden, zou een slechtere uitkomst zijn dan een ontbrekende logregel.

Hoe zie en verbreek je gekoppelde assistenten?

Onderaan de MCP-pagina in je dashboard staat de sectie "Gekoppelde assistenten". Daar staat elke actieve OAuth-koppeling op een eigen regel, en dat is de enige plek waar je overzicht hebt over wie er toegang heeft.

Per regel zie je vier dingen: de naam van de client, een badge met "Volledige toegang" of "Alleen-lezen", de datum waarop je gekoppeld hebt achter het label "Gekoppeld", en wanneer de koppeling voor het laatst gebruikt is achter "Laatst gebruikt". Is een koppeling nog nooit gebruikt, dan staat er "Nooit". Heb je nog niets gekoppeld, dan lees je "Er is nog geen AI-assistent gekoppeld."

Verbreken doe je met de knop "Loskoppelen" aan het einde van de regel. Je krijgt eerst de vraag "Deze assistent verliest toegang tot je account. Doorgaan?" en na bevestiging de melding "Koppeling verbroken." Vanaf dat moment zijn de tokens van die client ongeldig; een verzoek dat daarna binnenkomt, krijgt een 401 terug en de client moet de hele goedkeuringsflow opnieuw doorlopen als je hem weer wilt gebruiken.

Twee dingen die deze lijst niet toont. Verbindingen die met een API-sleutel werken, staan er niet in, want daar hoort geen goedkeuring bij; die trek je in door de sleutel op je API-pagina opnieuw te genereren. En de lijst toont geen geschiedenis van wat een assistent gedaan heeft; dat zit in het logboek aan de serverkant, niet in dit overzicht.

Een gewoonte die de moeite waard is: kijk hier eens per kwartaal. Je ziet dan in één oogopslag welke koppelingen je vergeten bent, en de kolom "Laatst gebruikt" vertelt je meteen welke je zonder nadenken kunt verbreken. Een koppeling die je zes maanden niet gebruikt hebt, voegt niets toe.

Automatisering: de gebeurtenisstroom en webhooks

Naast losse vragen kan de assistent ook meekijken met wat er verandert. Daarvoor zijn twee mechanismen: een gebeurtenisstroom die je opvraagt, en webhooks die het paneel naar jou stuurt.

De gebeurtenisstroom lees je met list_events, van oud naar nieuw, met een cursor zodat je niets mist. Dat is de eenvoudigste route voor iedereen die geen adres heeft waar het paneel naartoe kan sturen: wie lokaal ontwikkelt, wie geen vast IP-adres heeft, of wie gewoon geen zin heeft in een server die altijd aan staat. Je vraagt periodiek op wat er nieuw is en werkt dat af.

Gebeurtenis	Wanneer hij komt
order.created	de bestelling is aangemaakt
order.processing	de bestelling is opgepakt en loopt
order.completed	de bestelling is volledig geleverd
order.partial	de bestelling is deels geleverd
order.canceled	de bestelling is geannuleerd
order.updated	er is iets aan de bestelling veranderd
refill.created	er is een aanvulling aangevraagd
refill.updated	de status van een aanvulling is veranderd

Webhooks werken andersom: je registreert een https-adres met create_webhook en het paneel stuurt de gebeurtenissen daar naartoe. Je kunt aangeven op welke soorten je wilt abonneren; laat je dat leeg, dan krijg je ze allemaal. In het antwoord komt het ondertekeningsgeheim terug waarmee je kunt controleren dat een binnenkomend bericht echt van het paneel komt, en dat geheim wordt één keer getoond. Bewaar het meteen, want opnieuw opvragen kan niet.

Met list_webhooks zie je de geregistreerde adressen, de gebeurtenissen waarop ze geabonneerd zijn en de resultaten van de laatste bezorgingen. Met delete_webhook haal je er een weg, inclusief de bezorgingen die nog in de wachtrij stonden. De uitgebreide beschrijving van gebeurtenissen, de opbouw van de berichten en de manier waarop je de handtekening controleert, staat op de pagina met de API-documentatie en in de achtergrond op de pagina over de paneel-API.

Een realistische verwachting hierbij: webhooks laten opzetten door een assistent is handig, maar het ontvangen ervan blijft jouw infrastructuur. De assistent kan een adres registreren en het geheim doorgeven; hij kan geen server voor je bouwen die de berichten verwerkt.

Kant-en-klare commando's: order_status, find_service en reorder

MCP kent naast tools ook prompts: kant-en-klare commando's die je client als menu-item of slash-commando kan tonen. Er zijn er drie, en ze dekken de drie dingen die klanten het vaakst vragen.

Commando	Wat het doet	Argumenten
order_status	Vat je recente bestellingen samen en markeert wat vastzit of onvolledig is	count (standaard 10)
find_service	Vergelijkt drie tot vijf diensten voor jouw vraag en rekent de prijs uit, plaatst geen bestelling	request (verplicht), quantity
reorder	Herhaalt een eerdere bestelling, na jouw bevestiging	order_id (verplicht)

order_status haalt je bestellingen op met de servicegegevens erbij en somt per bestelling het nummer, de dienstnaam, de status, het aantal, het resterende aantal en het bedrag op. Bestellingen die niet zijn afgerond of waar een fout bij de uitvoerende partij op staat, worden apart uitgelicht met een suggestie: annuleren, aanvullen of gewoon wachten.

find_service is het commando dat je het vaakst gaat gebruiken. Je geeft in gewone taal op wat je zoekt, bijvoorbeeld Instagram-volgers, en optioneel een aantal. De assistent zoekt, kiest de meest redelijke opties en zet ze in een vergelijkende tabel met prijs, min en max, aanvullingsgarantie en gemiddelde doorlooptijd. Geef je een aantal op, dan rekent hij daar het bedrag bij. Wat dit commando met opzet niet doet, is bestellen: de keuze blijft bij jou.

reorder leest een eerdere bestelling, maakt een voorbeeld voor dezelfde dienst, dezelfde link en hetzelfde aantal, toont je het actuele bedrag en vraagt om bevestiging. Pas daarna wordt er besteld. Er zit ook een waarschuwing in: loopt er nog een bestelling op dezelfde link, dan hoort de assistent dat te melden voordat je akkoord geeft, omdat de uitvoerende partij een tweede bestelling op dezelfde link kan weigeren.

Hoe deze commando's in je client verschijnen, verschilt. Sommige clients tonen ze in een menu, andere achter een schuine streep, en weer andere tonen ze helemaal niet en moet je gewoon in woorden vragen wat je wilt. In dat laatste geval verlies je niets: de tools eronder zijn dezelfde.

Hoeveel verzoeken mag je assistent doen?

De limiet is 600 verzoeken per minuut per account. Dat is precies dezelfde bovengrens als die van de ontwikkelaars-API, en dat is bewust zo: het maakt niet uit of een verzoek van je assistent komt of uit je eigen code, ze tellen bij elkaar op in dezelfde teller.

Kom je erboven, dan krijg je HTTP 429 terug met een Retry-After-header die op 60 staat. De client hoort dan een minuut te wachten en het opnieuw te proberen. In de praktijk raak je deze grens met een gesprek nooit aan: een assistent doet er hooguit een handvol aanroepen per antwoord. Je raakt hem wel als je een script naast je assistent laat draaien dat honderden statusverzoeken per minuut doet.

Er is nog een tweede grens, op de laag van de ontwikkelaars-API: 900 verzoeken per minuut per IP-adres. Die telt per bronadres in plaats van per account, en hij is bedoeld tegen misbruik van buitenaf. Als eenmansgebruiker zul je er niet mee te maken krijgen; werk je met een bureau vanaf één kantoornetwerk met meerdere accounts, dan is het goed om te weten dat hij bestaat.

Twee gewoonten die helpen. Laat je assistent niet in een lus statussen ophalen "om te kijken of het al klaar is", maar gebruik list_events met een cursor of een webhook. En houd de paginagroottes klein: search_services geeft standaard twintig resultaten en maximaal vijftig, en dat is niet alleen een limiet van de server maar ook een gunst aan je model, dat met vijftig regels beter werkt dan met vijfhonderd.

Wat verandert er voor resellers en subpaneleigenaren?

Voor klanten van een subpanel werkt alles hetzelfde, met één verschil dat alles bepaalt: het loopt over het domein van dat subpanel. Het verbindingsadres is dat domein met /api/mcp/user erachter, de MCP-pagina staat in het dashboard van dat paneel, en het goedkeuringsscherm draait daar ook.

Dat is geen cosmetisch verschil. De OAuth-adressen worden opgebouwd uit de oorsprong van het verzoek, dus de uitgever van de tokens is het domein van het subpanel. In het ontdekkingsdocument, in het goedkeuringsscherm en in de metadata die de client leest, komt het adres van het hoofdpaneel nergens voor. Voor wie onder eigen merk verkoopt, is dat precies wat je wilt: je klant koppelt een AI-assistent aan jouw paneel en ziet niets anders.

Voor jou als eigenaar van een subpanel betekent het dat je klanten er iets bij krijgen zonder dat jij iets hoeft in te richten. De pagina staat er, het adres klopt met je eigen domein en de tekst staat in de taal die je klant heeft gekozen. Er is geen aparte instelling die je aan moet zetten en er zijn geen extra kosten aan verbonden; de bestellingen die je klanten via een assistent plaatsen, lopen door dezelfde afrekening als alle andere bestellingen.

Er is één ding dat je moet weten voordat je het aan je klanten aanprijst. Een account bestaat alleen op het paneel waar het is aangemaakt. Probeert een klant van jouw subpanel te koppelen via het adres van het hoofdpaneel, dan bestaat zijn account daar niet en lukt het inloggen niet. De oplossing is simpel maar niet vanzelfsprekend voor iemand die het adres ergens anders vandaan heeft: koppelen doe je altijd via het domein waar je account staat.

Denk je erover om als reseller te beginnen of wil je begrijpen hoe het subpanelmodel in elkaar zit, dan staan de details op de pagina over subpanelen en in de handleiding over reseller worden. Werk je voor meerdere klanten vanuit één account, dan is de pagina voor bureaus relevanter.

Aan de kant van de paneeleigenaar: de beheerserver

Deze paragraaf gaat over de andere server, en hij is er vooral om één ding duidelijk te maken: het paneel wordt met hetzelfde protocol beheerd als waarmee jij het gebruikt. Het is geen bijgebouw dat er later is aangeplakt.

De beheerserver staat op /api/mcp en werkt met één geheime sleutel in plaats van met OAuth. Is die sleutel niet ingesteld, dan is het adres volledig dicht en geeft het HTTP 503 terug; er is dus geen toestand waarin de beheerkant "per ongeluk open" staat. De sleutel mag als Authorization: Bearer, als eigen header of als queryparameter meekomen, en de vergelijking gebeurt in constante tijd.

De 57 tools bestrijken de gebieden die je van een paneelbeheer verwacht: overzicht en zoeken, gebruikers, bestellingen, bestelverzoeken, diensten, categorieën, aanbieders, betalingen, supporttickets, kortingsbonnen en instellingen. Er zitten een paar beschermingen in die de moeite van het noemen waard zijn: de laatste actieve beheerder kan niet worden gedegradeerd of geblokkeerd, geldbewegingen lopen in een transactie met een rijvergrendeling zodat er niets dubbel gebeurt, en elke aanroep gaat door hetzelfde logboek als de klantkant.

Meer hoef je er als klant niet van te weten. Het punt is dat de klantserver geen uitzondering is: dezelfde kern, dezelfde logging, dezelfde manier van fouten teruggeven, alleen met een andere sleutelbos en een ander bereik.

MCP, API of gewoon het paneel: wat gebruik je wanneer?

Er zijn nu drie manieren om hetzelfde te doen, en ze zijn geen concurrenten. Ze passen bij verschillende situaties, en de meeste mensen gebruiken er uiteindelijk twee.

Situatie	Beste keuze	Waarom
Eén bestelling, je weet welke dienst	het paneel	sneller dan uitleggen wat je wilt
Zoeken in een grote catalogus	MCP	filters op platform, prijs en garantie in gewone taal
Prijs uitrekenen voordat je beslist	MCP	preview_order geeft een exact bedrag
Tien tot vijftig bestellingen tegelijk	MCP of de API	bulk met een resultaat per regel
Honderden bestellingen per dag	de API	eigen code is voorspelbaarder dan een model
Onbewaakt, op een schema	de API	er hoort geen mens bij een schema
Statussen samenvatten	MCP	het model licht eruit wat vastzit
Betrouwbare gebeurtenisverwerking	de API met webhooks	je eigen code bepaalt de afhandeling
Saldo opwaarderen en support	het paneel	er zijn geen tools voor

De combinatie die in de praktijk het beste werkt: MCP voor het denkwerk en het paneel voor het geld. Je laat de assistent zoeken, vergelijken en rekenen, en de bestelling zelf plaats je waar je je het prettigst bij voelt. Wil je die scheiding afdwingen, dan zet je bij het koppelen het vinkje voor alleen-lezen aan en is de knip er structureel.

Voor wie richting echte automatisering wil: begin met MCP om te leren welke velden een dienst wil en hoe de prijzen uitpakken, en schrijf pas daarna code. De parameternamen zijn identiek, dus alles wat je in gesprekken leert, kun je één op één overzetten naar je integratie. Dat is de goedkoopste manier om een API te leren kennen die ik ken.

Problemen oplossen: veelvoorkomende fouten en wat ze betekenen

De meeste problemen met een MCP-koppeling zijn geen storingen maar verwacht gedrag dat je niet herkent. Hieronder staan de gevallen die je in de praktijk tegenkomt, met de reden en wat je eraan doet.

Wat je ziet	Wat er aan de hand is	Wat je doet
401 invalid_token	het toegangstoken is na 8 uur verlopen	de client ververst zelf met het vernieuwingstoken; gebeurt dat niet, koppel dan opnieuw
HTTP 405 in je browser of client	er werd een SSE-stroom geprobeerd met GET	het protocol accepteert alleen POST
HTTP 429	meer dan 600 verzoeken in een minuut	wacht zolang Retry-After aangeeft
"Dit koppelingsverzoek is ongeldig of verlopen."	de autorisatiecode was ouder dan 10 minuten, of de client is niet geregistreerd	start de flow opnieuw vanuit je client
Het tokenadres geeft 400	de client stuurde PKCE als plain	alleen S256 wordt geaccepteerd
Het teruggaveadres wordt geweigerd	redirect_uri komt niet overeen met wat er geregistreerd is	alleen het poortnummer van een lokaal adres mag afwijken
Het adres geeft 503	op de beheerserver ontbreekt de geheime sleutel	raakt alleen de paneeleigenaar
Je account wordt niet gevonden	een account van een subpanel bestaat alleen op dat domein	koppel via het juiste domein
cancel_not_supported	de dienst ondersteunt geen annulering	open een supportticket in het paneel
insufficient_balance	het bedrag is hoger dan je beschikbare saldo	waardeer op of verlaag het aantal
quantity_out_of_range	het aantal valt buiten de min en max van de dienst	lees de grenzen uit get_service

Twee algemene aanwijzingen. Foutcodes zijn vast, foutmeldingen zijn in jouw taal, en de assistent hoort de melding onverkort door te geven in plaats van er een oplossing bij te verzinnen. Krijg je van je assistent een verklaring die verdacht creatief klinkt, vraag dan om de letterlijke foutmelding.

En als er iets echt niet werkt, is de snelste test de curl-aanroep uit het onderdeel over API-sleutels. Komt daar een toollijst uit, dan staat de serverkant en zit het probleem in je client. Komt er een 401 uit, dan zit het in je identificatie. Dat onderscheid scheelt een half uur zoeken.

Veelgestelde vragen

Wat is MCP in één zin?

MCP staat voor Model Context Protocol en is een open standaard waarmee een AI-assistent tools van een externe dienst rechtstreeks kan aanroepen. In dit paneel betekent het dat je assistent diensten kan zoeken, prijzen kan berekenen en bestellingen kan beheren op jouw account. De koppeling loopt via een goedkeuringsscherm in het paneel, dus je hoeft geen sleutel over te typen.

Moet ik mijn paneelwachtwoord aan de assistent geven?

Nee. Je client krijgt nooit je wachtwoord te zien, ook niet tijdens het koppelen. Je logt in op het paneel zelf, keurt de koppeling goed op een scherm van het paneel, en de client krijgt daarna alleen een token met een beperkte geldigheid. Vraagt een client of een pagina wel om je paneelwachtwoord, dan komt dat niet van dit paneel en moet je stoppen.

Kan de assistent zonder mijn toestemming bestellen?

De serverinstructie draagt het model op om vóór het plaatsen van een bestelling expliciet om je akkoord te vragen, en de meeste clients vragen daarnaast zelf om bevestiging bij een tool die als destructief is gemarkeerd. Wil je zeker weten dat er niets besteld kan worden, dan zet je bij het koppelen het vinkje "Alleen-lezen toegang geven" aan. Dan bestaan de bestel-, annuleer- en aanvullingstools niet in die verbinding, en dan hangt het niet af van de vraag of het model zich aan een instructie houdt.

Welke AI-clients worden ondersteund?

Elke MCP-client die streamable HTTP en OAuth 2.1 met PKCE spreekt, kan koppelen. Er wordt niet op merknaam gefilterd, dus er is geen lijst met goedgekeurde clients. Voor clients die geen OAuth spreken maar wel een vaste header kunnen meesturen, is er de route met een API-sleutel. Wat er niet werkt, is een client die alleen een SSE-stroom kan openen, want die wordt hier niet aangeboden.

Hoe verbreek ik een koppeling en wat gebeurt er daarna?

Op de MCP-pagina in je dashboard staat bij elke gekoppelde assistent de knop "Loskoppelen". Je krijgt eerst een bevestigingsvraag en daarna de melding dat de koppeling verbroken is. Vanaf dat moment werken de tokens van die client niet meer en krijgt hij een 401 bij het volgende verzoek. Wil je hem later weer gebruiken, dan doorloop je de goedkeuringsflow opnieuw.

Hoe lang blijft mijn koppeling geldig?

Het toegangstoken is acht uur geldig en het vernieuwingstoken negentig dagen, waarbij het vernieuwingstoken bij elk gebruik wordt vervangen. In de praktijk merk je daar niets van: je client ververst zelf op de achtergrond zolang je hem regelmatig gebruikt. Laat je een koppeling maanden ongebruikt liggen, dan kan het gebeuren dat je opnieuw moet goedkeuren, en dat is een kwestie van één klik.

Kan de assistent mijn saldo opwaarderen?

Nee, daar bestaat geen tool voor. Opwaarderen doe je zelf in het paneel, net als geld opnemen, een supportticket openen of je wachtwoord wijzigen. Wat de assistent wel kan, is je saldo opvragen en je vertellen of een bestelling erin past voordat je hem plaatst.

Moet ik met OAuth of met een API-sleutel koppelen?

Gebruik OAuth voor alles waar een mens bij zit, want dan verschijnt de koppeling in je overzicht, kun je hem met één klik verbreken en kun je hem tot alleen-lezen beperken. Gebruik een API-sleutel voor scripts en servers waar geen browser bij past. Houd er rekening mee dat een verbinding met een sleutel altijd volledig bevoegd is: de beperking tot alleen-lezen bestaat alleen bij OAuth.

Zie ik in het paneel welke bestellingen de assistent heeft geplaatst?

Ja. Bestellingen die via de assistent zijn geplaatst, zijn gewone bestellingen en staan gewoon in je bestelgeschiedenis met dezelfde statussen en dezelfde knoppen. Daarnaast wordt elke toolaanroep in een logboek vastgelegd, met de client, de tool, de parameters en het resultaat, dus achteraf is te herleiden of een bestelling via de assistent of via het paneel is ontstaan.

Kunnen klanten van een subpanel ook een assistent koppelen?

Ja, en het werkt precies hetzelfde, alleen via het domein van dat subpanel. Het verbindingsadres, de MCP-pagina en het goedkeuringsscherm draaien allemaal op dat domein, en het adres van het hoofdpaneel komt nergens in beeld. Belangrijk daarbij: een account bestaat alleen op het paneel waar het is aangemaakt, dus koppelen via een ander domein lukt niet.

Wat gebeurt er als een tool een fout teruggeeft?

Een fout in een tool wordt niet als protocolfout teruggegeven maar als een gewoon antwoord met een foutindicatie erin en de melding als leesbare tekst. Daardoor kan het model de fout lezen en zichzelf corrigeren, bijvoorbeeld door een aantal binnen de toegestane grenzen te leggen. De foutcodes zijn vast, zoals insufficient_balance en quantity_out_of_range, en de melding staat in jouw taal.

Kost het gebruik van MCP extra?

Er zijn geen extra kosten aan de koppeling verbonden. Je betaalt voor de bestellingen die je plaatst, precies zoals wanneer je ze in het paneel had geplaatst, met dezelfde prijzen en dezelfde marges. Wat de AI-client zelf kost, is een zaak tussen jou en de aanbieder van die client.

Kan de assistent een bestelling annuleren of een aanvulling aanvragen?

Alleen als de dienst dat ondersteunt. Annuleren kan bij een dienst met annuleringsondersteuning zolang de bestelling nog niet is afgerond; kan het niet, dan komt cancel_not_supported terug en is een supportticket de weg. Een aanvulling kan alleen bij een afgeronde bestelling op een dienst met aanvullingsgarantie, en die is gratis en raakt je saldo niet.

Zo begin je: een verstandige eerste week

Begin klein en met alleen-lezen. Koppel je assistent met het vinkje voor alleen-lezen aan en gebruik hem een week lang uitsluitend om te zoeken en te rekenen. Je merkt dan snel waar hij je echt tijd bespaart en waar je hem niet vertrouwt, en je riskeert in die week geen cent. Voel je je er prettig bij, dan koppel je opnieuw zonder dat vinkje.

Test daarna één keer de hele keten met een kleine bestelling. Vraag de assistent om een dienst te zoeken, laat hem de prijs uitrekenen, geef akkoord voor een bescheiden aantal en kijk of de bestelling in je bestelgeschiedenis staat met het bedrag dat je verwachtte. Klopt dat, dan weet je dat de keten van zoeken tot afschrijving deugt en kun je opschalen.

Neem daarna deze drie gewoonten mee. Vraag altijd om het bedrag uit preview_order voordat je akkoord geeft, en accepteer geen bedrag dat het model zelf heeft uitgerekend. Kijk eens per kwartaal in "Gekoppelde assistenten" en verbreek wat je niet gebruikt. En houd de scheiding scherp tussen wat de assistent doet en wat jij beslist: hij levert de feiten, jij geeft het geld uit.

Wil je eerst het paneel zelf onder de knie krijgen voordat je een assistent koppelt, werk dan de complete paneelhandleiding van boven naar beneden af, of kijk op de pagina met veelgestelde vragen. Heb je nog geen account, dan begin je op de registratiepagina; de MCP-pagina staat daarna meteen in je menu onder "AI-assistent".