MCP Veranderde Mijn AI Van Chatbot Naar Echte Agent
Ik staarde dertig volle seconden naar mijn scherm, oprecht in verwarring.
Claude had zojuist een notitie aangemaakt in mijn Obsidian vault — niet omdat ik tekst kopieerde en plakte, niet omdat ik een Zapier-integratie gebruikte — maar omdat ik het vroeg. In gewoon Nederlands. "Maak een notitie over French press-koffie." En daar stond het, in mijn vault alsof ik het zelf had geschreven.
Dat was drie weken geleden. Sindsdien heb ik Claude verbonden met mijn taakbeheerder, mijn agenda, een web scraper, YouTube-transcripten en — ik maak dit niet op — Kali Linux. Mijn AI kan nu voor me hacken. Nou ja, een beetje. Maar het punt staat: er is iets fundamenteels veranderd, en de meeste ontwikkelaars met wie ik praat hebben het nog niet door.
De verandering heeft een naam. Het heet MCP — het Model Context Protocol. En zodra je begrijpt wat het doet, besef je dat de kloof tussen "AI-chatbot" en "AI-agent" geen ver verwijderd onderzoeksprobleem is. Het is een configuratiebestand.
Wat ik niet had verwacht: het moeilijkste deel was niet de technologie. Het moeilijkste was het afleren van hoe ik over AI dacht.
Het Probleem Waar Niemand Over Praat
Ik keek onlangs naar NetworkChuck's uitleg van MCP — een diepgaande video van 38 minuten die al 1,2 miljoen views heeft gepasseerd — en iets wat hij vroeg zei klikte op een manier die maanden van documentatie lezen niet had bereikt.
Hij vergeleek LLM's met mensen. Blijf even bij me.
Wanneer jij of ik een tool wil gebruiken — zeg ClickUp voor taakbeheer — doen we dat via een grafische interface. Knoppen, menu's, slepen en neerzetten. De GUI abstraheert alle onderliggende complexiteit weg. We hoeven het databaseschema of de API-eindpunten niet te kennen. We klikken gewoon.
LLM's haten GUI's. Ze kunnen er technisch mee omgaan (screenshot-gebaseerde agents bestaan), maar het is traag, onbetrouwbaar en voelt aan als iemand leren autorijden door ze foto's van stuurwielen te laten zien.
Geef ze dan gewoon API's? Dat is waarvoor API's zijn — om één programma programmatisch met een ander te laten praten. En ja, dit werkt. Maar hier zit de vangst die Chuck perfect raak omschreef: elke API heeft honderden eindpunten met unieke authenticatieschema's, parameterformaten en responsstructuren. De API van ClickUp alleen is al enorm. Die van Obsidian ook. Net als GitHub. Net als elke andere tool die je je AI wilt laten gebruiken.
Om een LLM via ruwe API's te verbinden met slechts vijf tools, zou je voor elk één aangepaste integratiecode moeten schrijven, voor elk één authenticatie afhandelen, voor elk één responses parsen, en de LLM vervolgens moeten leren welke eindpunten wanneer aan te roepen.
Ik heb dit gedaan. Voor een klantproject vorig jaar besteedde ik twee weken aan het bouwen van een aangepaste tool-calling laag voor GPT-4 die verbinding maakte met drie interne API's. Twee weken. Drie tools.
MCP verandert die vergelijking volledig.
Wat MCP Eigenlijk Is (Zonder De Hype)
Het Model Context Protocol is in de kern een gestandaardiseerde interface tussen LLM's en externe tools. Anthropic heeft het gemaakt, maar het is een industriestandaard geworden die wordt omarmd door OpenAI, Google en vrijwel elk AI-toolingbedrijf.
Zie het als USB-C voor AI-tools. Vóór USB-C had elk apparaat zijn eigen eigen aansluiting. Je had een la vol kabels nodig. USB-C zei: "Hier is één standaard. Iedereen gebruikt dit." MCP doet hetzelfde voor LLM-naar-tool-communicatie.
Hier is de architectuur in eenvoudige termen:
LLM (Claude, GPT, Llama)
↕ spreekt MCP-protocol
MCP Server (draait lokaal of op afstand)
↕ verwerkt alle rommelige API-zaken
Externe Tool (Obsidian, ClickUp, GitHub, etc.)
De MCP-server zit tussen jouw AI en de tools die het nodig heeft. Het verwerkt authenticatie, API-aanroepen, het parsen van responses — alles. De LLM hoeft niets te weten over REST-eindpunten of OAuth-tokens. Het ziet gewoon een lijst met beschikbare "tools" die in gewone taal zijn omschreven:
create_note— Maak een nieuwe notitie aan in de vaultsearch_vault— Zoek naar inhoud in alle notitiesappend_content— Voeg inhoud toe aan een bestaande notitie
De LLM kiest de juiste tool, geeft de parameters door en krijgt gestructureerde resultaten terug. Dat is het. Geen aangepaste code. Geen API-gevecht.
Maar hier is het deel dat me recht overeind deed zitten — en dit verbindt zich met iets veel groters.
Van Chatbot Naar Agent: De Drie Niveaus
Terwijl ik MCP-servers opzette, stuitte ik op Jeff Su's uitleg van AI-agents — een video die bijna 4 miljoen views heeft gehaald — en het kristalliseerde iets wat ik had gevoeld maar niet kon verwoorden.
Jeff verdeelt AI in drie niveaus, en zodra je ze ziet, kun je ze niet meer onzien:
Niveau 1: Basis-LLM. Je geeft input, je krijgt output. ChatGPT vragen een e-mail te opstellen? Prima. Vragen wanneer je volgende vergadering is? Het faalt. Het weet het niet. Het heeft geen toegang. Het genereert gewoon tekst op basis van trainingsdata.
Niveau 2: AI-workflow. Je voegt voorgedefinieerde paden toe. "Als de gebruiker vraagt naar agendagebeurtenissen, query eerst Google Calendar, dan reageer." Dit werkt — totdat de gebruiker iets vraagt wat je niet had voorzien. "Hoe is het weer op de dag van mijn vergadering?" Je workflow kent alleen Google Calendar, geen weer-API's. Elke nieuwe mogelijkheid vereist dat een mens handmatig een nieuw pad toevoegt.
Hier is het kernprincipe van Jeff's analyse: hoe veel stappen je ook toevoegt — honderden, duizenden — als een mens degene is die beslist welk pad te volgen, is het nog steeds gewoon een workflow. Geen agent.
Niveau 3: AI-agent. De LLM zelf beslist wat te doen. Het redeneert ("Ik heb agendadata EN weerdata nodig"), selecteert tools ("Ik gebruik eerst Google Calendar API, dan een weerdienst"), voert uit, evalueert het resultaat en itereert indien nodig.
Het framework hierachter heet ReAct — Reason and Act. De agent denkt na over wat het nodig heeft, neemt actie met tools, observeert het resultaat en beslist of het doorgaat of een definitief antwoord teruggeeft.
En hier wordt MCP het ontbrekende stuk. Want een AI-agent heeft tools nodig om te handelen. Zonder tools denkt het alleen hardop. MCP geeft het handen.
MCP Opzetten Met Docker (Het Praktische Gedeelte)
Ik leerde dit op de harde manier: probeer MCP-servers niet handmatig te installeren bij je eerste poging. Gebruik Docker. Het verwerkt isolatie, afhankelijkheden en opruimen automatisch.
Hier is mijn exacte installatieproces:
Stap 1: Installeer Docker Desktop
Haal het op van de officiële site voor jouw besturingssysteem. Op Mac:
# Download en installeer Docker Desktop van docker.com/desktop
# Of via Homebrew:
brew install --cask docker
# Verifieer installatie
docker --version
# Docker version 28.x.x
# Schakel MCP Toolkit in via Docker Desktop:
# Settings → Beta Features → Docker MCP Toolkit → Enable
Op Windows heb je eerst WSL 2 of Hyper-V als backend nodig. Linux is eenvoudig — installeer gewoon Docker Engine en Desktop.
Stap 2: Blader Door De MCP-Catalogus
Docker Desktop wordt nu geleverd met een MCP-catalogus — een samengestelde lijst van officiële MCP-servers. Open Docker Desktop, ga naar het MCP Toolkit-gedeelte en blader door de catalogus. Ik was oprecht verrast over wat er beschikbaar is:
- Obsidian — Volledige vault-toegang (lezen, schrijven, zoeken)
- Brave Search — Webzoeken met privacy
- Fetch — Inhoud van elke URL ophalen
- YouTube Transcripts — Transcript van elke video ophalen
- DuckDuckGo — Zoeken zonder API-sleutels
- Airbnb — Zoek naar accommodaties (ja, echt)
Een server toevoegen is één klik. Sommige hebben API-sleutels nodig (Brave, bijvoorbeeld), maar vele werken out of the box.
Stap 3: Verbind Je LLM-Client
Docker MCP Toolkit ondersteunt meerdere clients:
- Claude Desktop (gratis tier werkt)
- Cursor (voor codegeoriënteerd werk)
- LM Studio (voor lokale modellen zoals Llama)
Klik op "Connect" naast je client. Docker werkt automatisch het MCP-configuratiebestand bij dat je client leest. Voor Claude Desktop bevindt dit zich op ~/Library/Application Support/Claude/claude_desktop_config.json op Mac.
Zo ziet de configuratie er achter de schermen uit:
{
"mcpServers": {
"obsidian": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "OBSIDIAN_API_KEY=your-key-here",
"mcp/obsidian"
]
},
"fetch": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/fetch"]
},
"youtube-transcript": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/youtube-transcript"]
}
}
}
Elke server draait als een geïsoleerde Docker-container. Wanneer Claude een tool moet gebruiken, start het de container op, doet de aanroep en de container wordt afgesloten. Schoon. Geïsoleerd. Geen afhankelijkheidsconflicten.
Stap 4: Test Het
Herstart Claude Desktop. Klik op het instellingenpictogram — je zou "MCP Docker" moeten zien. Klik erop om te verifiëren dat je tools zijn geladen.
Vraag dan gewoon: "Zoek in mijn Obsidian vault naar notities over projectplanning."
Claude zal herkennen dat het de search_vault-tool heeft, om toestemming vragen om deze te gebruiken (alleen de eerste keer als je dat kiest), en resultaten uit je echte vault teruggeven.
De eerste keer dat ik dit zag werken, zei ik letterlijk "Meen je dit?" hardop. In een lege kamer. Om 2 uur 's nachts.
Een Aangepaste MCP-Server Bouwen
De catalogus is geweldig voor veelgebruikte tools. Maar de echte kracht ontgrendelt zich wanneer je aangepaste servers bouwt voor jouw specifieke behoeften.
NetworkChuck's video toonde iets wilds: hij bouwde een MCP-server die Kali Linux-tools omwikkelt. Zijn AI kon nmap-scans uitvoeren, Metasploit gebruiken en doelen inventariseren — allemaal via natuurlijke taal.
Ik bouwde iets minder dramatisch maar praktischer voor mijn dagelijks werk: een MCP-server die de CMS API van mijn blog omwikkelt. Hier is het skelet:
#!/usr/bin/env python3
"""Custom MCP Server for mejba.me blog CMS."""
import json
import httpx
from mcp.server import Server
from mcp.types import Tool, TextContent
app = Server("blog-cms")
BASE_URL = "https://mejba.me/api"
API_TOKEN = "your-api-token"
@app.list_tools()
async def list_tools():
return [
Tool(
name="create_draft",
description="Create a new blog post draft with title, content, and tags",
inputSchema={
"type": "object",
"properties": {
"title": {"type": "string", "description": "Post title"},
"content": {"type": "string", "description": "Markdown content"},
"tags": {"type": "array", "items": {"type": "string"}}
},
"required": ["title", "content"]
}
),
Tool(
name="list_recent_posts",
description="List the most recent blog posts with their status",
inputSchema={
"type": "object",
"properties": {
"limit": {"type": "integer", "default": 10}
}
}
),
Tool(
name="get_post_analytics",
description="Get view count and engagement metrics for a post",
inputSchema={
"type": "object",
"properties": {
"slug": {"type": "string", "description": "Post slug"}
},
"required": ["slug"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
headers = {"Authorization": f"Bearer {API_TOKEN}"}
if name == "create_draft":
response = httpx.post(
f"{BASE_URL}/posts",
headers=headers,
json={
"title": arguments["title"],
"content": arguments["content"],
"tags": arguments.get("tags", []),
"status": "draft"
}
)
data = response.json()
return [TextContent(
type="text",
text=f"Draft created: {data['slug']} (ID: {data['id']})"
)]
elif name == "list_recent_posts":
limit = arguments.get("limit", 10)
response = httpx.get(
f"{BASE_URL}/posts?limit={limit}", headers=headers
)
posts = response.json()
result = "\n".join(
f"- [{p['title']}] ({p['status']}) - {p['views']} views"
for p in posts
)
return [TextContent(type="text", text=result)]
elif name == "get_post_analytics":
response = httpx.get(
f"{BASE_URL}/posts/{arguments['slug']}/analytics",
headers=headers
)
data = response.json()
return [TextContent(
type="text",
text=json.dumps(data, indent=2)
)]
if __name__ == "__main__":
import asyncio
from mcp.server.stdio import stdio_server
asyncio.run(stdio_server(app))
Wikkel dit in een Dockerfile en elke MCP-compatibele client kan via natuurlijke taal jouw blog CMS gebruiken. "Hey Claude, maak een conceptartikel over MCP met deze tags." Klaar.
Het patroon werkt voor alles met een API: interne dashboards, databases, IoT-apparaten, CI/CD-pijplijnen. Als het een API heeft, kun je het in minder dan een uur in een MCP-server wikkelen.
De Eerlijke Fouten Die Ik Maakte
Ik wil transparant zijn over wat me struikelde, want ik denk dat dit fouten zijn die de meeste mensen zullen maken.
Fout 1: MCP-agents behandelen als traditionele automatisering. Mijn eerste instinct was starre workflows te bouwen — "Als ik X zeg, doe dan Y." Maar het hele punt van het agentparadigma is dat de LLM zelf beslist welke tools te gebruiken en wanneer. Ik bleef het te strak begrenzen. De beste resultaten kwamen wanneer ik Claude een doel gaf en het de toolsequentie liet uitzoeken.
Fout 2: Het toestemmingsmodel negeren. MCP-servers kunnen toegang hebben tot je bestanden, je API's, je netwerk. Claude Desktop vraagt om toestemming voor elk toolgebruik (tenzij je het permanent toestaat). Ik schakel de bevestigingsprompts uit voor het gemak en vergat toen dat ik een MCP-server verbonden had met mijn e-mail. Claude "organiseerde" behulpzaam mijn inbox op basis van een terloopse opmerking die ik maakte. Les geleerd: houd toestemmingen beperkt totdat je de workflow vertrouwt.
Fout 3: Perfectie verwachten van lokale modellen. Ik probeerde MCP-verbonden agents te draaien via LM Studio met Llama 3.1. De toolselectie was merkbaar slechter dan Claude. Lokale modellen werken, maar ze hebben meer expliciete prompting nodig over wanneer en hoe tools te gebruiken. Claude en GPT-4 zijn aanzienlijk beter in autonome toolselectie — voorlopig.
Hier is een controversieel standpunt: ik denk dat de meeste "AI-agent"-producten die nu worden verkocht eigenlijk Niveau 2-workflows zijn die een agentskostuum dragen. Ze volgen voorgedefinieerde paden met wat LLM-besluitvorming erin gestrooid. Echte Niveau 3-agents — waarbij de LLM echt redeneert over toolselectie, uitvoeringsvolgorde en autonoom itereert — zijn zeldzaam buiten onderzoeksdemo's en een handvol echte implementaties.
Dat gezegd hebbende, is MCP de infrastructuurlaag die echte agents mogelijk maakt. Het protocol bestaat. De tools bestaan. Wat inhaalt, is het redeneervermogen van de modellen zelf.
Hoe Dit Er In De Praktijk Uitziet
Na drie weken het bouwen van MCP-gebaseerde workflows, hier is mijn concrete voor/na:
Blogonderzoek — Vroeger: 2-3 uur handmatig YouTube-video's bekijken, aantekeningen maken, documentatie kruislings raadplegen. Nu: 25 minuten. Claude haalt YouTube-transcripten op via MCP, doorzoekt mijn Obsidian-onderzoeksvault naar gerelateerde notities en stelt een gestructureerde outline op. Ik bewerk vanaf daar.
Klantprojectopzet — Vroeger: 45 minuten voor het aanmaken van repo's, CI/CD opzetten, toevoegen aan projecttracker. Nu: 8 minuten. Claude maakt de GitHub-repo aan, initialiseert de projectstructuur, voegt het toe aan ClickUp met mijlpalen en stuurt een Slack-melding naar het team. Allemaal via MCP-verbonden tools.
Dagelijkse standup-voorbereiding — Vroeger: 15 minuten ClickUp, GitHub-PR's en Slack-kanalen controleren. Nu: 2 minuten. "Waar heb ik gisteren aan gewerkt en wat staat er voor vandaag nog open?" Claude controleert alle drie en geeft me een samenvatting.
De tijdsbesparingen zijn echt. Niet theoretisch. Niet "tot X%." Dit zijn mijn werkelijke cijfers van de afgelopen drie weken.
Maar — en dit is belangrijk — de eerste opzet kostte me een volledig weekend. Docker installeren, servers configureren, verbindingen testen, debuggen wanneer dingen niet werkten. Zodra het eenmaal draait, is het magisch. Er naartoe komen vereist geduld.
Wat Hierna Komt
NetworkChuck noemde aan het einde van zijn video iets wat de meeste kijkers volgens mij over het hoofd zagen: de Docker MCP Gateway. Dit maakt je lokale MCP-servers op afstand toegankelijk — wat betekent dat tools zoals n8n, Make.com of elk extern automatiseringsplatform verbinding kan maken met je MCP-servers via het netwerk.
Denk na over wat dat betekent. Je AI-agent is niet langer beperkt tot je lokale machine. Je zou een n8n-workflow kunnen hebben die een Claude-agent triggert die je aangepaste MCP-servers gebruikt die draaien op een VPS. De agent redeneert over wat te doen, gebruikt tools via MCP en geeft resultaten terug — allemaal zonder menselijke tussenkomst.
We zijn er nog niet voor de meeste productiegevallen. Maar de kloof tussen "demo" en "productie" sluit sneller dan ik had verwacht.
Als je één ding meeneemt uit dit artikel: wacht niet totdat AI-agents "klaar" zijn. De infrastructuur — MCP, Docker-containers, tool-calling LLM's — is er nu. De ontwikkelaars die deze stack vandaag leren, zullen een enorm voordeel hebben wanneer de redeneervermogens inhalen.
Ik zet mijn workflow erop in. En eerlijk gezegd? Drie weken in, en het loont al.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur opschalen? Ik help je graag.
- Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
