Ik bouw nu ongeveer een jaar met agent workflows, en één vraag komt steeds terug van ontwikkelaars: moet ik hiervoor een CLI-tool gebruiken of een MCP-server bouwen? Het leek me in eerste instantie vanzelfsprekend, maar hoe meer ik het uitlegde, hoe meer ik me realiseerde dat er hier oprechte verwarring is. Laat me het ophelderen.

Wat vergelijken we hier?

Als ik in deze context CLI zeg, heb ik het niet over het uitvoeren van commando's in je terminal. Ik heb het over hoe AI-agents externe tools aanroepen. Er zijn twee hoofdpatronen:

Shell commando-uitvoering werkt door shell commando's direct uit te voeren. De agent voert in wezen iets uit als npm run build of python script.py en parseert de uitvoer.

MCP (Model Context Protocol) is een open protocol ontwikkeld door Anthropic dat JSON-RPC 2.0 gebruikt voor communicatie tussen AI-applicaties en externe systemen. In plaats van shell commando's uit te voeren, roept de agent gestructureerde tools aan die door een MCP-server worden blootgesteld. De server ontdekt beschikbare tools via de tools/list methode, en de agent voert ze uit met tools/call met getypeerde parameters.

Het belangrijkste verschil: shell commando's geven de agent een ruwe string om uit te voeren, terwijl MCP de agent gestructureerde, type-veilige tooldefinities geeft met duidelijke inputschema's.

Wanneer shell commando's zinvol zijn

Laat me een concreet voorbeeld geven. Op mijn portfolio-website heb ik scripts die redirects genereren van mijn oude WordPress blogposts naar nieuwe Next.js pagina's. Ik heb hiervoor geen MCP-server gebouwd. Waarom? Omdat het een eenvoudige, eenmalige bewerking is die al bestond als een Node-script.

Shell commando's winnen wanneer:

Je al een werkend script of commando hebt
De taak eenvoudig is en geen complex state management vereist
Je aan het prototypen bent en snel wilt werken
De tool goed ingeburgerd is en een stabiele CLI-interface heeft

Een ander scenario: ik gebruik ffmpeg voor audioprocessing in mijn projecten. Wil ik een MCP-server bouwen voor ffmpeg? Absoluut niet. Het is een decennia-oude tool met een stabiele CLI-interface. De agent hoeft alleen de juiste commando-string te construeren.

De agent heeft hier geen type-veilige tooldefinities nodig. Het hoeft alleen argumenten door te geven aan een extern proces.

Wanneer MCP uitblinkt

Nu komt het punt waarop MCP de investering waard wordt. Ik heb een MCP-server gebouwd voor mijn RFP-zoektool. De functionaliteit is helemaal niet eenvoudig. Het is een full-text search over duizenden overheidscontractdocumenten, met filtering, ranking en AI-gestuurde samenvattingen.

Als ik dit als shell commando's had gedaan, zou de agent complexe commando-strings construeren met tientallen argumenten. Het zou foutgevoelig en moeilijk te onderhouden zijn. In plaats daarvan stelt de MCP-server duidelijke tools bloot met correcte inputschema's: search_rfps(query, filters) en get_rfp_details(id). De agent roept deze aan met getypeerde argumenten, en de MCP-server handelt de complexiteit af.

MCP wint wanneer:

Je complexe, meerstaps workflows hebt die de juiste structuur nodig hebben
Je type-veilige interfaces nodig hebt met JSON Schema voor inputs
Je iets vanaf nul bouwt dat herhaaldelijk zal worden gebruikt
Je wilt dat de agent beschikbare tools dynamisch ontdekt
Je gedetailleerde controle nodig hebt over wat de agent kan doen
Je zowel lokale (STDIO transport) als externe (HTTP transport) implementaties wilt ondersteunen

Het protocol ondersteunt ook capability negotiation tijdens de initialisatie van de verbinding, zodat servers kunnen adverteren welke functies ze ondersteunen en clients zich dienovereenkomstig kunnen aanpassen.

Wat met interactie met API's?

Dit komt vaak voor. Als de agent een REST API moet aanroepen, moet hij dan curl gebruiken of een MCP-server bouwen?

CLI-aanpak betekent dat de agent commando-strings construeert zoals curl -X GET https://api.example.com/data -H "Authorization: Bearer $TOKEN". Het werkt, maar de agent moet elk header, query parameter en authenticatie detail correct krijgen. Als één ding fout gaat, mislukt de aanroep.

MCP-aanpak stelt tools bloot zoals get_data(filters) of search_customers(query). De MCP-server handelt de HTTP-aanroepen, authenticatie, foutafhandeling en retries intern af. De agent geeft alleen gestructureerde parameters door.

Voor een snelle eenmalige aanroep is CLI prima. Voor alles wat je regelmatig gebruikt, is MCP schoner. De server kan OAuth token vernieuwing, rate limiting en correcte foutmeldingen afhandelen. Je agent hoeft niets van dat alles te weten.

Het beslissingskader

Dit is hoe ik er nu over denk:

Begin met shell commando's als: de taak een eenvoudige wrapper is rond een bestaand commando, het een eenmalige of laagfrequente bewerking is, of je gewoon snel iets werkends nodig hebt.

Ga over op MCP als: de tool complexe inputs heeft die validatie nodig hebben, vaak zal worden gebruikt in agent workflows, of juiste tool discovery nodig heeft. De overhead van het opzetten van een MCP-server is alleen zinvol wanneer de complexiteit van de tool dit rechtvaardigt.

Er is ook een overweging van de leercurve. Je team moet begrijpen hoe MCP werkt - het is een open protocol met SDK's voor meerdere talen. Als jij de enige bent die agent tools bouwt en je wilt gewoon iets gedaan krijgen, zijn shell commando's prima. Als je tools bouwt voor een team of herbruikbare infrastructuur wilt, betaalt MCP zich terug.

Wat met het combineren van beide?

Dat kan, en dat moet je ook doen wanneer het gepast is. Ik heb een MCP-server voor mijn blog die complexe bewerkingen afhandelt, zoals het genereren van vertalingen of het beheren van post-metadata. Maar het roept intern nog steeds shell commando's aan voor zaken als het uitvoeren van Node-scripts of het benaderen van git. MCP is de orchestratielaag, shell commando's zijn een van de tools die het kan gebruiken.

Zie het niet als of/of. Zie MCP als een manier om agents een schonere interface te geven naar je bestaande tools, inclusief shell commando's. Het protocol gebruikt JSON-RPC 2.0 berichten, ongeacht het transport, of dat nu STDIO is voor lokale processen of Streamable HTTP voor externe servers.

De volgende keer dat je iets bouwt voor een agent, vraag jezelf dan af: is dit een eenvoudige wrapper rond een bestaand commando, of heeft het zijn eigen gestructureerde interface nodig met type-veilige tooldefinities? Dat antwoord zal je vertellen welke weg je moet inslaan.

workflow-automation

Kiezen tussen CLI en MCP voor uw AI-agentworkflows

Blijf Op de Hoogte