Het hele verschil tussen een AI-chatbot en een AI-agent is op mijn machine elf regels JSON. Dit is de echte, volledige .mcp.json in de root van de repository van deze website:
{
"mcpServers": {
"laravel-boost": {
"command": "php",
"args": [
"artisan",
"boost:mcp"
]
}
}
}
Voordat dat bestand bestond, was Claude een zeer belezen consultant: hij kon me over Laravel vertellen, en ik deed het kopiëren, plakken, uitvoeren en terugrapporteren. Nadat dat bestand bestond, kon Claude mijn databaseschema bevragen, Tinker draaien, mijn routes opsommen en mijn foutlogs lezen, direct, midden in het gesprek, zonder dat ik voor koerier hoefde te spelen. Dat is de hele transformatie van chatbot naar agent, en ze is kleiner en minder mystiek dan de meeste uitleg doet voorkomen. Laat me je de versie geven die ik graag als eerste had gelezen.
Wat MCP echt is, zonder de hype
Model Context Protocol, dat Anthropic in november 2024 open source maakte, is een standaardinterface tussen een AI-model en de buitenwereld. De vergelijking waardoor het bij mij eindelijk klikte, is USB-C: daarvoor was elke verbinding tussen tool en model een eigen kabel, een integratie die iemand met de hand moest bouwen voor één model en één tool. MCP standaardiseert de stekker. Een tool stelt één keer een MCP-server beschikbaar; elke client die MCP ondersteunt, Claude en inmiddels de meeste grote AI-clients, omdat het ecosysteem in de loop van 2025 op het protocol is samengekomen, kan hem gebruiken.
Technisch gezien vertelt een MCP-server het model drie dingen: dit zijn mijn tools (getypeerde functies die je mag aanroepen), dit zijn mijn resources (data die je mag lezen), en zo roep je ze aan. Het model beslist wanneer het ze aanroept. Die laatste bijzin is wat een agent tot agent maakt: de loop van beslissen, handelen, observeren en opnieuw beslissen gebeurt aan de kant van het model, niet aan de jouwe.
De drie niveaus: chatbot, assistent, agent
Ik denk over de verschuiving in drie niveaus, omdat “agent” voor alle drie wordt gebruikt.
Niveau 1, chatbot: het model weet dingen. Jij vraagt, het antwoordt, jij doet al het werk. Elke AI-interactie van vóór tools.
Niveau 2, assistent die tools gebruikt: het model kan handelen, maar elke actie is een eenmalige boodschap waar jij toezicht op houdt: “bevraag deze tabel”, “haal deze pagina op”.
Niveau 3, agent: het model rijgt acties aan elkaar richting een doel, zonder dat jij die keten uitschrijft. “Zoek uit waarom het contactformulier een 500 geeft” wordt uit zichzelf: de log lezen via de ene tool, de route checken, het schema inspecteren, een Tinker-snippet draaien om het te reproduceren, de fix voorstellen. Niemand heeft die volgorde geschreven. Het model stelde hem samen uit de beschikbare tools.
MCP maakt het model niet slimmer. Het maakt niveau 3 mogelijk door het model een gereedschapskist te geven die groot genoeg is om samenstellen de moeite waard te maken.
Hoe dit eruitziet in een echte codebase
De Boost-server uit mijn elf regels levert tools als database-schema, database-query, tinker, list-routes, last-error en search-docs, een versiebewuste zoekfunctie voor de Laravel-documentatie. Het cumulatieve effect op een werkdag is moeilijk te overschatten, en het zie je in alledaagse momenten, niet in demo's.
Een concreet geval uit deze repo: comments zijn hier polymorf, en een agent moet weten hoe ze worden opgeslagen voordat hij het model aanraakt. Oude wereld: ik schakel over naar een databaseclient, inspecteer, maak een screenshot of plak, leg uit. Nieuwe wereld: hij roept database-schema aan en leest de morph-kolommen zelf. Geen contextwissel en, cruciaal, geen kans voor mij om mijn eigen schema verkeerd te parafraseren, wat ik absoluut heb gedaan. Ik heb de volledige setup uitgeschreven in mijn gids voor Laravel Boost MCP, als je een Laravel-stack draait.
Het inzicht dat pas na maanden dagelijks gebruik naar boven komt: de waarde zit niet in één enkele tool call. Het zit erin dat het model niet langer werkt vanuit mijn beschrijving van het systeem, maar vanuit het systeem zelf.
Voorbij de lokale server: het aanbod op afstand
Lokale servers zoals Boost zijn de helft van het plaatje. De andere helft zijn remote connectors, MCP-servers die de diensten zelf draaien. In mijn eigen Claude-omgeving zijn op dit moment onder andere Figma, HeyGen, Higgsfield, Canva, Semrush, Supabase en Postman op deze manier gekoppeld. Hetzelfde protocol, nul lokale setup, en ineens zijn “genereer de b-roll-beelden voor dit script” of “haal de tokens van dit design op” tool calls binnen één gesprek. Dat aanbod drijft mijn code-first Figma-workflow aan en, op systeemniveau, het AI-besturingssysteem dat ik op Claude Code draai.
Zo begin je zonder mijn fouten te maken
Begin met één server, op projectniveau. Zet een .mcp.json in één repo met die ene server die je dagelijkse pijnpunt raakt. Weersta de catalogus, wat me brengt bij:
Tool sprawl is echt en kost je dubbel. Elke gekoppelde server voegt zijn lijst met tools toe aan de context van het model. Te veel servers betekent meer opties, meer getwijfel en vaker de verkeerde tool. Mijn regel: een server verdient zijn plek door wekelijks gebruikt te worden. Tien goed gekozen servers verslaan veertig indrukwekkende; ik houd een shortlist bij in mijn overzicht van de beste MCP-servers.
Behandel tools die kunnen schrijven als productietoegang, want dat zijn ze. Een tool die kan bevragen, kan vaak ook wijzigen. Kies voor read-only modi waar ze worden aangeboden, controleer wat elke server beschikbaar stelt en houd destructieve mogelijkheden achter expliciete goedkeuring. De agent is precies zo voorzichtig als de slechtste tool die je hem gaf.
Waar dit naartoe gaat
Het protocol nestelt zich in de saaie, dragende rol waarin goede protocollen uiteindelijk belanden: onzichtbaar. De interessante frontier is een laag omhoog verschoven, naar welke tools je combineert, onder welke guardrails je ze draait en welke vaste workflows je erbovenop bouwt. Dat is een onderwerp waar ik steeds op terugkom, want zodra het leidingwerk standaard is, zit het vakmanschap in het systeem dat je erboven samenstelt.
De elf regels JSON bovenaan deze post zijn echt waar het bij mij begon. De Laravel Boost-setup en de Figma-workflow waarnaar hierboven gelinkt wordt, draaien er allebei op. Mijn projectenpagina laat zien wat ik sindsdien heb gebouwd.
