Model Context Protocol (MCP), en aantekeningen over het implementeren van een MCP-server in Go

Langere lezing over MCP-specs en implementatie in GO

Inhoud

Hier hebben we een beschrijving van het Model Context Protocol (MCP), korte aantekeningen over hoe je een MCP-server in Go kunt implementeren, inclusief berichtstructuur en protocolespecificaties.

Robots en MCP

Overzicht van het Model Context Protocol (MCP)

Model Context Protocol (MCP) is een open, gestandaardiseerde kaderstructuur (introduceerd door Anthropic in het laatste kwartaal van 2024) voor het verbinden van AI-taalmodellen met externe gegevensbronnen, tools en systemen. Het doel is om het probleem van de “N×M integratie” op te lossen door een universele interface te bieden voor dingen zoals het lezen van bestanden, het uitvoeren van functies (tools) en het gebruiken van contextuele prompts over verschillende toepassingen. MCP is geen eigenaarsprotocol of intern protocol; het is een open standaard met een officiële specificatie en open-source referentieimplementatie. In feite hebben grote AI-leveranciers (waaronder OpenAI en Google DeepMind) ondersteuning voor MCP aangekondigd na de introductie, wat aantoont dat het bedoeld is als een breed aangenomen standaard in plaats van een leveranciersspecifieke oplossing.

Doel en architectuur van MCP

MCP richt zich op het standaardiseren van hoe toepassingen context bieden aan LLMs – de vaak gebruikte analogie is “een USB-C-poort voor AI-toepassingen”. Door een gemeenschappelijk protocol te definiëren, laat MCP AI-assistenten en tools zonder aangepaste, enkele integraties gladjes communiceren met databases, bestandssystemen, APIs en andere bronnen. Dit helpt taalmodellen relevante, up-to-date antwoorden te genereren door hen veilig toegang te geven tot de gegevens die ze nodig hebben.

Architectuur: MCP volgt een client-servermodel met duidelijke rolverdeling:

  • MCP-host: De ouder toepassing (bijvoorbeeld een chatclient of IDE) die verbindingen beheert. Het bevat één of meer MCP-clients (connectors).
  • MCP-client: Een connectorinstantie (binnen de host) die een 1:1-sessie met een MCP-server opzet. De client beheert de levensloop van de sessie, routeert berichten en toont eventuele gebruikersrechten of beveiligingsbeleid.
  • MCP-server: Een lichte service die specifieke mogelijkheden (toegang tot bepaalde gegevens of functies) via het MCP-protocol blootstelt. Elke server kan een gegevensbron (bestanden, DB, API, enz.) of tool omvatten. Meerdere servers kunnen parallel lopen, elk met verschillende integraties.
  • Gegevensbronnen/diensten: De werkelijke bronnen waarmee servers communiceren – dit kan lokale bestanden en databases of externe diensten (web-API’s, SaaS-apps, enz.) omvatten. De MCP-server fungeert als een adapter voor deze bronnen, zodat de LLM alleen toegang heeft tot gegevens via het gestandaardiseerde protocol.

Deze ontwerpstrategie is geïnspireerd op het Language Server Protocol (LSP) uit de IDE-wereld. Net zoals LSP elke editor in staat stelt om elke programmeertaal te ondersteunen via een gemeenschappelijk protocol, laat MCP elke AI-toepassing verbinding maken met elke data/tool-integratie die MCP spreekt. Deze loskoppeling betekent dat AI-toolontwikkelaars een MCP-server maar één keer kunnen schrijven en deze werkt met veel AI-clients, en AI-toepassingsontwikkelaars kunnen nieuwe integraties eenvoudig toevoegen door een MCP-server in te schakelen, zonder aangepaste integratiecode.

Protocol en berichtstructuur

Communicatie: MCP-communicatie is opgebouwd uit blijvende, toestandsbewuste sessies met JSON-RPC 2.0-berichten. Alle aanvragen en reacties voldoen aan het JSON-RPC-formaat (met een "jsonrpc": "2.0"-veld, methode namen, parameters en correlerende ID’s). Ofwel de client of de server kan aanvragen of meldingen sturen, waardoor er twee-richtingse communicatie mogelijk is. Een MCP-sessie begint meestal met een handshake:

  • De client start met een initialize-aanvraag, waarbij een protocoolversie wordt voorgesteld en de ondersteunde functionaliteiten worden aangekondigd. Bijvoorbeeld kan de client aangeven dat het servergedreven “sampling”-aanvragen kan verwerken of bepaalde wortels voor bestandstoegang kan bieden. De server reageert met zijn eigen ondersteunde protocoolversie en functionaliteiten, waarmee wordt bepaald welke functionaliteiten voor deze sessie zijn ingeschakeld (MCP gebruikt een functionaliteitsnegotiatiestelsel dat vergelijkbaar is met optionele functionaliteiten in LSP). Als kritieke functionaliteiten of versie onverenigbaar zijn, wordt de verbinding op een beleefde manier afgesloten.
  • Na overeenstemming stuurt de client een initialized-melding om de gereedheid aan te duiden. Daarna kunnen normale operaties verdergaan. De sessie blijft open voor een continue uitwisseling van JSON-RPC-berichten totdat een van beide zijden een afsluiting uitvoert.

Transports: MCP stelt geen enkele transportmethode voor – het werkt over elke kanaal die JSON-tekst kan dragen. Vaak wordt een MCP-server uitgevoerd als een subproces en communiceert via STDIO (stdin/stdout-pijpen) voor lokale integraties. Dit is vergelijkbaar met hoe taalserver werken en is handig voor lokale tools (de host kan het serverproces starten en berichten doorsturen). Alternatief kunnen MCP-servers als onafhankelijke diensten worden uitgevoerd die toegankelijk zijn via HTTP. De MCP-specificatie definieert een streaming HTTP-transport waarbij de server een enkele HTTP-eindpunt blootstelt voor JSON-RPC-aanroepen (clients POST-aanvragen, en de server kan reageren of resultaten streamen via Server-Sent Events voor lange operaties). In beide gevallen zijn berichten UTF-8 JSON-lijnen, en het protocol ondersteunt het streamen van reacties en servergestarte berichten (de HTTP+SSE aanpak laat de server meldingen of gedeeltelijke resultaten asynchroon pushen). Veiligheidsrichtlijnen adviseren dat lokale servers zich binden aan localhost en Origin-headers valideren om ongewenste externe toegang te voorkomen, en dat voor externe servers juiste authenticatie (zoals tokens of OAuth-stromen) wordt gebruikt.

Berichtformaat: MCP maakt gebruik van de drie berichttypen van JSON-RPC: Aanvragen, Reacties en Meldingen. Een aanvraag bevat een id, een method-string en (optioneel) params (meestal een JSON-object van argumenten). De ontvanger moet reageren met een overeenkomstige reactie (met een overeenkomstige id) die ofwel een result ofwel een error-object bevat. Meldingen zijn unidirectionele berichten met een method en params, maar zonder id (zodat er geen reactie op volgt). MCP legt een aantal regels op bovenop de basis JSON-RPC (bijvoorbeeld moet id niet leeg zijn en mag niet worden hergebruikt tijdens een sessie) om duidelijkheid te waarborgen.

Sessie en toestand: De verbinding wordt beschouwd als toestandsbewust – de client en server onderhouden context over elkaars functionaliteiten en mogelijk enige sessietoestand (zoals abonnementen op wijzigingen, lopende operaties, enz.). Er zijn ook gedefinieerde procedures voor een vloeiende afsluiting (bijvoorbeeld kan een client een afsluitaanvraag sturen of eenvoudigweg het transport sluiten; servers moeten de opruiming verwerken, en beide zijden implementeren time-outs voor vastgelopen operaties). Foutafhandeling volgt JSON-RPC-conventies (foutreacties bevatten een code en een bericht) en de specificatie definieert standaard foutcodes voor bepaalde omstandigheden (zoals toegang geweigerd, tool niet gevonden, enz.). MCP biedt ook hulpmiddelen voor cross-cutting zaken: bijvoorbeeld zijn er ingebouwde meldingen voor voortgangsupdates, annulering van een lange aanvraag (CancelledNotification), logboekmeldingen en configuratieveranderingen. Deze helpen bij het beheren van lange of complexe interacties (de client kan een lopende toolaanroep annuleren, of de server kan waarschuwingen naar de client loggen, enz.).

MCP-functies en operaties

Zodra geïnitialiseerd is, maakt een MCP-sessie het mogelijk om context en opdrachten op een gestructureerde manier uit te wisselen. De kernfuncties van de MCP-serverzijde zijn Prompts, Resources en Tools (waarvan de server aangeeft of ze ondersteunen tijdens de initialisatie):

  • Prompts: Vooraf gedefinieerde promptsjablonen of instructies die de server aan de client kan leveren. Deze zijn meestal gebruikersgestart helpers (de gebruiker kiest expliciet een prompt om in te voegen in het gesprek, bijvoorbeeld via een slashcommand in de UI). MCP biedt methoden om beschikbare prompts te tonen en de inhoud van een prompt op te halen. Bijvoorbeeld kan een client prompts/list aanroepen om een lijst met promptsjablonen te krijgen (elke met een naam, beschrijving en optionele parameters). Om een prompt op te halen, gebruikt de client prompts/get met de naam van de prompt en eventuele argumentwaarden; de server geeft dan de promptinhoud terug (meestal als een set van berichten die de client in de context van de LLM injecteert). Prompts laten complexe instructies of workflows hergebruiken (bijvoorbeeld een “code review sjabloon”) die een gebruiker op aanvraag kan activeren. Servers geven een prompts-functionaliteit aan (met optionele subfunctionaliteiten zoals listChanged om de client te informeren als de set prompts dynamisch verandert).

  • Resources: Gestructureerde data of inhoud die context biedt aan het model. Resources zijn meestal dingen zoals bestanden, documenten, database-records – informatie die een AI-assistent kan lezen of refereren. MCP standaardiseert hoe resources worden geïdentificeerd en overgedragen: elke resource heeft een URI-identificatie (bijvoorbeeld file:///pad/naar/bestand.txt of een aangepaste schema voor databases). Clients kunnen via resources/list vragen welke resources beschikbaar zijn (de server kan een directoryboom, een lijst met recente documenten, enz. blootstellen). De servers reactie bevat metadata voor elke resource (URI, naam, type, beschrijving, enz.). Vervolgens kan de client de inhoud van een specifieke resource aanvragen met resources/read, door de URI te doorgeven. De server reageert met de resourceinhoud, die tekst kan zijn (voor bestanden), of gestructureerde data (MCP ondersteunt verschillende inhoudstypen, zoals tekst, JSON, binair, enz., met MIME-types). Er is ook ondersteuning voor resource sjablonen (parameteriseerde resources geïdentificeerd door sjabloon-URI’s, die de client kan invullen, bijvoorbeeld een databasequery waarbij de gebruiker een parameter opgeeft). Als ingeschakeld, kunnen servers meldingen sturen wanneer resources veranderen (bijvoorbeeld notifications/resources/updated) of clients toestaan om veranderingen op een resource te abonneren (resources/subscribe). In de ontwerp van MCP zijn resources toepassingsgestuurd context: de hosttoepassing (client) beslist meestal welke resourceinhoud daadwerkelijk in de modelprompt wordt gevoegd (vaak na gebruikersbevestiging of op basis van UI-context).

  • Tools: Uitvoerbare functies of acties die de server blootstelt voor het model om aan te roepen. Tools vertegenwoordigen operaties die de AI kan uitvoeren – bijvoorbeeld een externe API aanroepen, een databasequery uitvoeren, een e-mail verzenden of een bestand wijzigen. Elke tool heeft een naam en een JSON-schema voor zijn invoer (en eventueel uitvoer)parameters, zodat de AI (of client) weet welke argumenten verwacht worden. Tools zijn meestal modelgestuurd: het idee is dat het taalmodel (agent) beslist wanneer en of een tool wordt gebruikt tijdens een gesprek om de gebruikersaanvraag te vervullen. Voor veiligheid kan een menselijke gebruiker of de hostapplicatie toolgebruik bemiddelen (bijvoorbeeld een bevestigingsklik vereisen). Het gebruik van tools in MCP omvat twee hoofdoperaties: lijsten en aanroepen. Een client kan tools/list aanroepen om beschikbare tools en hun schema’s te krijgen. Bijvoorbeeld kan een server een tool get_weather met een beschrijving en een invoerschema dat een “locatie”-string vereist, aankondigen. Vervolgens, wanneer het model besluit een tool te gebruiken (of de gebruiker het aanroept), stuurt de client een tools/call-aanvraag met de naam van de tool en een JSON-object van argumenten. De server voert de functie uit en geeft het resultaat terug, meestal als een result.content-veld dat tekst of gestructureerde data kan bevatten (MCP ondersteunt het teruggeven van meerdere inhoudsdelen, zoals tekst plus een afbeelding, enz., hoewel tekst het meest voorkomt). Een eenvoudig voorbeeld: het aanroepen van een get_weather-tool kan een tekstpayload zoals “Huidige weer in New York: 72°F, gedeeltelijk bewolkt” als inhoud teruggeven voor de assistent om weer te geven. Tools kunnen ook fouten aangeven (de reactie heeft een isError-vlag of een foutobject als iets misgaat). Net zoals prompts en resources kan de tools-functionaliteit een optionele listChanged-vlag hebben om te informeren wanneer beschikbare tools tijdens runtime veranderen (bijvoorbeeld een dynamisch plugin geladen of verwijderd).

Naast de bovenstaande serveraangeboden functionaliteiten, definieert MCP ook clientaangeboden functionaliteiten (functionaliteiten die servers kunnen gebruiken als de client deze ondersteunt). Deze omvatten Sampling, Roots en Elicitation:

  • Sampling stelt een server in staat om de client (en zijn LLM) te vragen om modelinference uit te voeren binnen de sessie. Bijvoorbeeld kan een server een LLM-aanroep initiëren (bijvoorbeeld om een keten van gedachten te voortzetten of iets te samenvatten) door een aanvraag zoals sampling/request te sturen – de client zou dan het model aanspreken en het resultaat teruggeven. Dit stelt agente gedrag in staat waarbij de server het AI kan laten helpen bij zijn eigen subtaken. (Alle dergelijke acties zijn onderhevig aan gebruikersgoedkeuring en beleid – bijvoorbeeld zou een gebruiker moeten instemmen om een server te laten activeren voor extra queries.)

  • Roots stelt de server in staat om vragen te stellen of te opereren binnen bepaalde toegestane bestandssysteem- of URI-wortels. De client kan een lijst van “root”-mappen/URI’s geven die de server mag toegang tot, via roots/list. Dit is een beveiligingsfunctie die ervoor zorgt dat de server de grenzen kent (bijvoorbeeld welke mapstructuren het kan lezen).

  • Elicitation laat de server toe om de client te vragen om meer informatie van de gebruiker op te halen als dat nodig is. Bijvoorbeeld, als een tool een ontbrekend stuk informatie nodig heeft dat niet is geleverd, kan de server een elicitatieaanvraag sturen, die de client (UI) zou omzetten in een gebruikersprompt (“De X-integratie heeft uw API-sleutel nodig, voer deze in”). Op die manier kan de server interactief invoer via de client verzamelen.

Deze functionaliteiten zijn allemaal optioneel en worden vooraf onderhandeld. Een belangrijk ontwerpaspect van MCP is dat functionaliteitsonderhandeling plaatsvindt tijdens de initialisatie – de client en server melden welke van de bovenstaande functionaliteiten ze ondersteunen, zodat beide zijden weten welke operaties beschikbaar zijn in de sessie. Bijvoorbeeld, als een server de tools-functionaliteit niet declareert, zal de client geen tools/list- of tools/call-operaties met deze server uitvoeren. Deze uitbreidbaarheid betekent dat MCP zich kan ontwikkelen met nieuwe functionaliteiten terwijl het achterwaartse compatibiliteit behoudt (onondersteunde methoden worden eenvoudigweg niet gebruikt als ze niet zijn onderhandeld).

Implementaties, SDKs en het bouwen van een MCP-server (vooral in Go)

Officiële specificatie en documentatie: De autoritaire MCP-specificatie is openbaar beschikbaar, inclusief een formele schema van alle berichttypen. Het wordt onderhouden op de Model Context Protocol-website en GitHub. De specificatie is gedefinieerd in een TypeScript-schema-bestand (met een overeenkomstig JSON-schema) dat precies documenteert alle aanvragen, reacties en structuren. De documentatiesite (modelcontextprotocol.io) biedt gidsen, een FAQ en gedetailleerde uitleg van elk kenmerk en berichttype, evenals een “MCP Inspector”-tool voor interactieve foutopsporing. Hoewel MCP nog niet (nog) een IETF- of ISO-standaard is, wordt het ontwikkeld als een open standaard met gemeenschapsinput en gebruikt bekende RFC 2119-termen voor vereisten. Het is een evoluerend protocol (versies zijn met datumstempels gemarkeerd; bijvoorbeeld 2025-06-18 is een recente revisie), met een versiebeleid om veranderingen te beheren.

Referentieimplementaties: Anthropic openbaarde een aantal MCP-serverconnectors en SDKs toen MCP werd ingevoerd. Er is een GitHub-organisatie modelcontextprotocol die de specificatie en verschillende repositories host. Opvallend is een “servers”-repository die een verzameling vooraf gebouwde MCP-serverimplementaties bevat voor veelvoorkomende diensten en gegevensbronnen. Deze dienen als referentieintegraties en kunnen vaak direct worden gebruikt of als sjablonen voor aangepaste servers dienen. Bijvoorbeeld bevat de officiële repo servers voor Google Drive (bestandstoegang en zoekopdrachten in Google Drive), Slack (werkplekberichten en kanaalinhoud), GitHub/Git (code repository context), PostgreSQL (alleen-lezen databasequery’s met schema-informatie), Google Maps (locatie- en richting-API), Puppeteer (webbrowsing en web scraping), en veel meer. Door deze servers te installeren of uit te voeren, kan een AI-toepassing zoals Claude of Cursor direct deze integratie krijgen. Er is ook een gemeenschapsgeleide MCP registratie dienst (open source in Go) voor het indexeren van beschikbare servers, en veel bijdragen van derde partijen die MCP uitbreiden naar verschillende domeinen (van CRM’s tot blockchain-gegevens).

SDKs en bibliotheken: Om het bouwen van eigen MCP-servers/clients te faciliteren, zijn er officiële SDKs beschikbaar in meerdere talen. Tot 2025 biedt het project SDKs voor TypeScript/Node, Python, Java (en Kotlin), C# (ontwikkeld met Microsoft), Ruby (met Shopify), Swift, en andere. Deze bibliotheken hanteren de protocolplumbing – bijvoorbeeld het beheren van de JSON-RPC-transport, het implementeren van het specificatieschema en het bieden van helper-API’s om tools te registreren of resources te serveren. Bijvoorbeeld kan de TypeScript-SDK worden gebruikt om snel een server in Node.js te schrijven, en de Python-SDK stelt het integreren van MCP in Python-toepassingen mogelijk. De SDK-approach betekent dat ontwikkelaars geen JSON-RPC-berichten handmatig hoeven te construeren of de volledige statemachine moeten implementeren; in plaats daarvan roepen ze hoog niveau methoden aan om aanvragen te sturen of functionaliteiten te publiceren.

Go-implementatie: Go is geworden een populaire keuze voor MCP-servers vanwege zijn prestaties en concurrentiekracht (goed voor het afhandelen van meerdere gelijktijdige aanvragen). Een officiële Go-SDK is nu beschikbaar, onderhouden in samenwerking met het Go-team bij Google. (Dit werd aangekondigd rond april 2025 en de eerste stabiele release is gepland voor augustus 2025.) De Go-SDK biedt een pakket mcp voor het bouwen van clients/servers en een jsonschema-helper voor tool-schemata. Met behulp van de Go-SDK kunnen ontwikkelaars een MCP-server met slechts een paar aanroepen maken. Bijvoorbeeld kan je een nieuwe server instantiëren met een naam en versie, en vervolgens tools toevoegen via AddTool door een tooldefinitie (naam, beschrijving, invoerschema) en een Go-handlerfunctie te leveren die wordt uitgevoerd wanneer die tool wordt aangeroepen. De SDK zorgt ervoor dat de tool in het protocol wordt blootgesteld (het wordt aangekondigd in tools/list en tools/call-aanvragen worden verwerkt). Op dezelfde manier kun je resources of prompts blootstellen met analoog API’s. Uiteindelijk draait de server – bijvoorbeeld server.Run(ctx, mcp.NewStdioTransport()) start het verwerken van JSON-RPC-berichten via stdio tot de client zich losmaakt. Aan de clientkant kan de Go-SDK een subproces starten en verbinding maken via mcp.NewCommandTransport(exec.Command("myserver")), en dan de client session.CallTool(ctx, params) kan aanroepen om een tool aan te roepen en het resultaat gemakkelijk in Go-code te verkrijgen.

Voorbeeld: De officiële Go-SDK-documentatie laat een eenvoudige “greeter”-server zien. De server registreert een tool "greet" die een naam neemt en een begroetingsstring retourneert. De client roept vervolgens deze tool op naam aan en print het resultaat. Dit illustreert het basispatroon: tool definiëren -> client roept tool aan -> resultaat verkrijgen. Achter de schermen correspondeert dit met JSON-RPC-berichten ("method": "tools/call", params: {"name": "greet", ...} en de reactie die result.content bevat met tekst) zoals gedefinieerd door de MCP-specificatie.

Voor de officiële Go-SDK was vrijgegeven, creëerde de gemeenschap hun eigen Go-bibliotheken. Opvallend is Ed Zynda’s mcp-go project (mark3labs/mcp-go) dat veel gebruikt werd en het ontwerp van de officiële SDK beïnvloedde. Een andere bibliotheek, mcp-golang door Metoro, bood een Go-implementatie en API (de Dev community blogpost door Elton Minetto gebruikt deze bibliotheek in het vroege deel van 2025). Deze gemeenschaps-SDK’s lieten Go-ontwikkelaars vroeg met MCP experimenteren – bijvoorbeeld toont een tutorial hoe je een MCP-server bouwt die Braziliaanse postcodes (CEP) opzoekt door een “zipcode”-tool bloot te stellen via de Metoro mcp-golang-bibliotheek. In dat voorbeeld registreert de Go-server een functie die een externe API aanroept om een adres te vinden op basis van een ZIP, en retourneert het resultaat als tekst – waardoor een AI-assistent op aanvraag adresinformatie kan ophalen via MCP. Een ander handleiding laat zien hoe je een aangepaste in-memory database (DiceDB) als een MCP-server verpakt met de mark3labs mcp-go-SDK: het definieert een ping-tool om de DB-verbinding te controleren en andere tools voor data-operaties. Deze voorbeelden tonen hoe eenvoudig het kan zijn om een MCP-integratie te maken: de meeste code is gewoon de businesslogica (API-aanroepen, DB-query’s, enz.), terwijl de SDK de JSON-RPC-aansluiting verwerkt.

Bouwen van een MCP-server in Go (Tutorial Highlights)

Om het proces te schetsen, hieronder een typische stroom met de Go SDK of een vergelijkbare bibliotheek:

  1. Server instellen: Initialiseer een nieuwe serverinstantie met basisinformatie (naam, versie en declareer ondersteunde functionaliteiten). Bijvoorbeeld in Go: server := mcp.NewServer("MyServer", "1.0.0", nil) zal een server maken die (standaard) kernprotocolfuncties ondersteunt. Je kunt specifieke functionaliteiten zoals prompts/hulpmiddelen/resources activeren via opties of eenvoudigweg door die functionaliteiten te registreren (het toevoegen van een hulpmiddel of resource impliceert die functionaliteit).

  2. Functionaliteiten registreren: Voeg de functionaliteiten toe die je wilt tonen:

    • Als je hulpmiddelen wilt tonen, definieer dan de schema’s en handlers voor elk hulpmiddel. Bijvoorbeeld met de AddTool van de Go SDK: geef een mcp.Tool{Name: "...", Description: "..."} en een handler functie die de aanroep aanvraag verwerkt en een resultaat teruggeeft (dat kan tekst of andere inhoud bevatten). De SDK genereert automatisch een JSON Schema voor invoer op basis van de parameter typen van de handler (of je kunt het expliciet opgeven).
    • Als je resources wilt tonen, gebruik je mogelijk een API om resource lijsten te registreren of een callback voor het lezen van inhoud. In de Python SDK bijvoorbeeld kun je een ResourceProvider subklasse; in Go is de SDK nog in ontwikkeling, maar je zou waarschijnlijk functies moeten bieden voor het tonen en lezen van resources. Elke resource moet een stabiele URI hebben.
    • Als je prompts wilt tonen, definieer dan prompt sjablonen (die statische bestanden of strings kunnen zijn) en registreer ze met namen en optionele parameters. De server zal ze publiceren zodat de client ze kan ophalen en tonen aan gebruikers.

  3. Transport implementeren: Beslis hoe de server moet draaien. Voor lokale gebruik is stdio het eenvoudigst – bijvoorbeeld server.Run(ctx, mcp.NewStdioTransport()) in Go zal beginnen met het lezen van JSON-RPC van stdin. Als je server netwerkgeoriënteerd moet zijn, kun je een HTTP handler implementeren die de Go SDK gebruikt om JSON-RPC via HTTP aan te nemen (de officiële Go SDK bevat mogelijk binnenkort ook een helper voor HTTP/SSE transport).

  4. Client testen: Je kunt de server testen met een MCP-compatibele client. Bijvoorbeeld ondersteunt Anthropic’s Claude 2 (Claude for Desktop) het laden van lokale MCP-servers; je zou Claude configureren om te starten of te verbinden met je serverbinary. Er is ook een CLI-tool genaamd mcp-cli en de MCP Inspector GUI om servers te testen zonder een volledige AI-client – deze tools sturen MCP-aanvragen naar je server en tonen de resultaten, wat helpt bij het debuggen.

  5. Beveiliging & toegangsrechten: Bij het bouwen van een server, overweeg dan authenticatie en beperkingen. Voor lokale servers kan de host het draaien met bepaalde OS-rechten of API-sleutels via de omgeving bieden. Voor externe servers gebruik je auth headers of OAuth flows. MCP bevat een autorisatie spec voor HTTP transports (de server kan een token vereisen en de client kan het versturen). Zorg altijd dat de server alleen toegang heeft tot data die de gebruiker heeft toegestaan (bijvoorbeeld respecteer de hoofdmap die de client heeft opgegeven en lek geen data elders) – de MCP richtlijnen benadrukken gebruikersaanvaarding, dataprisiviteit en hulpmiddelveiligheid als fundamenteel.

In samenvatting is MCP een formele maar flexibele protocol om LLMs te verbinden met de buitenwereld. Het is niet een interne API gekoppeld aan één bedrijf, maar een open standaard met toenemende adoptie en een rijke ecosysteem van integraties. Het protocol definieert duidelijke berichtstructuren (op basis van JSON-RPC) en een reeks operaties (methoden voor prompts, tools, resources, enz.) die elke compatibele client/server kan implementeren. Officiële documentatie en specificaties zijn beschikbaar, en er zijn talloze SDKs, bibliotheken en voorbeeldservers (inclusief in Go) die het implementeren makkelijker maken. Door MCP te gebruiken, kunnen ontwikkelaars AI-gebaseerde toepassingen bouwen die veilig bestaande data en services kunnen gebruiken, zonder de integratie logica opnieuw te moeten uitvinden voor elk nieuw model of dataset.