Inside the Model Context Protocol (MCP): Architectuur, Motivatie & Intern Gebruik

Introductie

LLM-gestuurde applicaties hebben een dringende behoefte gecreëerd voor modellen om toegang te krijgen tot actuele, domeinspecifieke data uit uiteenlopende bronnen. MCP pakt dit aan door een gestandaardiseerd, universeel protocol te bieden waarmee applicaties dynamisch data en functionaliteiten kunnen ontsluiten voor elke LLM-gestuurde applicatie.

MCP Overzicht

In de kern volgt het Model Context Protocol (MCP) een op JSON-RPC gebaseerde client-serverarchitectuur waarin een host-applicatie verbinding kan maken met meerdere servers:

• MCP Hosts zijn LLM-gestuurde applicaties zoals Claude Desktop, IDE's of AI-tools die toegang willen tot data via MCP.
• MCP Clients implementeren het protocol aan de clientzijde in verschillende programmeertalen. Zij vormen de brug waarmee de MCP Hosts verbinding maken met de MCP Servers.
• MCP Servers ontsluiten specifieke data en functionaliteiten via het MCP-protocol. Een server kan drie hoofdtypen functionaliteiten bieden:
  • Resources zijn data die de MCP-servers beschikbaar stellen om door applicaties te worden gelezen. Dit kunnen bestandsinhouden, API-antwoorden, etc. zijn. Resources worden beheerd door de applicatie; de applicaties bepalen hoe deze in de gebruikersstroom worden opgenomen.
  • Tools zijn functionaliteiten en data die door de MCP-servers worden ontsloten. Een Kubernetes MCP-server kan bijvoorbeeld tools bieden voor het ophalen van alle pods en het verwijderen van een pod. Tools worden beheerd door het model. LLM's beslissen op basis van de gegeven context om deze aan te roepen.
  • Prompts zijn sjabloonbare gebruikersinteracties of workflows die door de MCP-server worden aangeboden. Deze worden door de gebruiker beheerd. LLM-applicaties bepalen hoe deze worden getoond, zodat de gebruiker de juiste prompt kan selecteren.

Transport

Transportlagen bepalen hoe een MCP Client en Server met elkaar communiceren.

STDIO

In deze configuratie is de MCP Client binnen de MCP Host verantwoordelijk voor het opstarten van de MCP Server op dezelfde machine. Communicatie tussen de MCP Client en MCP Server verloopt via STDIN en STDOUT. Hierbij communiceert één MCP Server slechts met één enkele MCP client.

Een typische configuratie ziet er als volgt uit:

Voorbeeld: U kunt de MCP Server van GitHub lokaal uitvoeren met Docker en een Personal Access Token (PAT)

GitHub - github/github-mcp-server: GitHub's officiële MCP Server  

Autorisatie

Normaliter kan de autorisatie op twee manieren plaatsvinden:

1. Gebruikers kunnen omgevingsvariabelen gebruiken om hun token door te geven aan het MCP Server-proces. Dit is de meest gebruikte methode.
2. Een MCP Server kan de OAuth2 device flow implementeren. De officiële MCP-specificatie vermeldt hierover echter niets expliciet.

Beperkingen

• Het apparaat van de gebruiker, waarop de LLM-gestuurde applicatie draait, moet Docker of Node/Python geïnstalleerd hebben. Hoewel dit voor een ontwikkelaar geen probleem is, vermindert het de kring van mogelijke gebruikers van de MCP Server aanzienlijk.
• Aangezien de MCP Server lokaal op het apparaat van de gebruiker staat en draait, worden upgrades bewerkelijk en wordt snelle iteratie belemmerd.
• Webapps die in de browser draaien, kunnen dit niet gebruiken.
• Zonder OAuth2 device flow moeten gebruikers hun tokens voor elke MCP Server handmatig configureren. Tokens worden vaak niet veilig opgeslagen op het apparaat en rotatie is bewerkelijk.

Gezien deze beperkingen is STDIO-transport ongeschikt voor het bouwen van aangepaste MCP Servers bovenop de eigen diensten, databronnen of SaaS-abonnementen (zoals GitHub of Slack) van een bedrijf. Het blijft echter nuttig voor developer tool-toepassingen in IDE's.

Streamable HTTP

Streamable HTTP stelt MCP Servers in staat om meerdere MCP clients te verwerken die verbinding maken en communiceren via het HTTP-protocol. Dit neemt een groot deel van de beperkingen van het STDIO-transport weg. Met name:

1. De MCP Server hoeft niet langer op het apparaat van de gebruiker te worden gehost; deze kan overal worden gehost.
2. Nieuwe functionaliteiten die aan de MCP-server worden toegevoegd, zijn direct beschikbaar voor alle gebruikers.
3. Webapps die in de browser draaien, kunnen dit gebruiken.

Autorisatie

Autorisatie binnen deze transportlaag is actief in ontwikkeling. De meest recente specificatie van 2025-03-26 vermeldt:

1. MCP Auth-implementaties moeten voldoen aan OAuth 2.1.
2. MCP Auth-implementaties dienen Dynamic Client Registration te volgen.

Een typische autorisatiestroom ziet er ongeveer zo uit:

In de bovenstaande stroom fungeert de MCP Server die tokens uitgeeft zowel als Resource Server en als Autorisatieserver. Dit is onpraktisch voor MCP Servers voor Slack, GitHub, enz., waar de provider al zijn eigen OAuth2 Autorisatieserver heeft geïmplementeerd. Interne bedrijfsdiensten achter door een IDP geleverde Autorisatieservers kampen met hetzelfde probleem (bijv. een ArgoCD-installatie achter een door Okta geleverde Autorisatieserver).

De specificatie staat toe om dit te delegeren aan een externe autorisatieserver, maar de MCP Server moet dan wel zijn eigen token uitgeven en de relatie met het externe token beheren. Dit doet alle voordelen van een externe autorisatieserver teniet, aangezien de MCP Server alsnog veilig tokenbeheer en de OAuth2-routes moet implementeren.

Beperking

• MCP Servers met autorisatie vereisen infrastructuur zoals een database om de levenscyclus van hun tokens veilig op te slaan en te beheren. Elke MCP Server zou in feite zijn eigen Autorisatieserver worden, wat redundant en onmogelijk te onderhouden is binnen een organisatie. De community werkt actief aan het aanpassen van de autorisatiespecificatie om dit te verbeteren.
• Providers zoals Atlassian, Sentry, Slack, GitHub, enz. ondersteunen geen Dynamic Client Registration (DCR) of zelfs OAuth2 public clients. Het bouwen van MCP Servers bovenop deze providers wordt daardoor moeilijker voor de community en vraagt meer werk van de provider. Atlassian heeft recent zijn eigen MCP Server gepubliceerd, maar de DCR-implementatie daarvan staat alleen localhost en een select aantal redirect URI's toe, zoals Claude, etc.

De Aanpak van TrueFoundry

Bij TrueFoundry willen we dat onze collega's hun Atlassian-, Sentry-, Slack-, GitHub- en andere accounts actief kunnen koppelen aan LLM's als extra context. We willen er ook voor zorgen dat elke medewerker alleen toegang heeft tot resources of acties kan uitvoeren via LLM's waarvoor zij geautoriseerd zijn. MCP + OAuth2 lijkt de perfecte manier om dit te ontsluiten.

• We willen ons concentreren op het schrijven van kwalitatief hoogwaardige MCP-servers om data en functionaliteiten efficiënter te ontsluiten voor LLM's. We willen dit veilig doen, met inachtneming van de RBAC-grenzen die binnen de provider zijn gedefinieerd.
• We willen geen extra Autorisatieservers onderhouden voor verschillende MCP Servers. We willen de bestaande OAuth2-functionaliteiten van de providers hergebruiken.
• Providers ondersteunen meestal alleen OAuth2 confidential clients. DCR en public clients zijn vaak niet eens een optie.
• De MCP Autorisatiespecificatie verandert nog actief en is in ontwikkeling. We kunnen niet wachten tot deze stabiliseert voordat we hiermee aan de slag gaan.

Gezien het bovenstaande hebben we de volgende architectuur ontwikkeld.

Hierin bevinden zich enkele componenten.

MCP Servers

We hebben HTTP MCP Servers geschreven voor providers zoals Slack, Sentry, Atlassian, GitHub, enz., volgens het Streamable HTTP-transport.

Deze MCP Servers fungeren als proxy tussen de LLM en de HTTP API's van de provider. Merk op dat dit geen 1:1 vertaling is. De HTTP API's van deze providers bevatten veel onnodige informatie die de LLM gemakkelijk van de wijs kan brengen en het contextvenster kan vervuilen. Een list pod-tool op een Kubernetes MCP-server bevat bijvoorbeeld veel dubbele inhoud omdat de pod-specificatie zich over meerdere pods herhaalt. Grote velden, zoals managedFields, zijn voor de meeste gebruikersverzoeken niet nodig. Andere SaaS-providers hebben geneste bovenliggende entiteiten, velden die niet functioneel zijn (zoals Avatar URL), enz. Dit is waar we de meeste van onze ontwikkeltijd aan willen besteden. Uiteindelijk hebben we een systeem in MCP nodig dat LLM's helpt het datamodel van een systeem te ontdekken en vervolgens dynamisch te zoeken naar specifieke velden van resources.

Deze MCP-servers verwachten een HTTP Authorisation-header en sturen deze rechtstreeks door naar de HTTP API van de provider.

Registreren van MCP Servers op TrueFoundry

Na het uitrollen van de MCP Servers maken we OAuth2 Apps of confidential clients aan voor elke provider. Zo ziet dat eruit voor Slack.

Hierboven ziet u ook dat de autorisator redirect URI is geconfigureerd. Dit ziet er meestal uit als https://base-url/mcp-integrations/oauth2/callback.

Vervolgens integreren we de MCP Server samen met de URL.

We kunnen de scopes gebruiken om deze hele integratie alleen-lezen te maken, als we dat willen, of permissies geven op specifieke resourcetypen. Zelfs als de MCP-server tools heeft om resources te "schrijven" en de gebruiker "schrijf"-toegang heeft, zal de LLM niet automatisch dezelfde rechten krijgen.

De MCP Server selecteren op de TrueFoundry Gateway en Autoriseren

Zodra de integratie is voltooid, kunnen we de MCP Server selecteren in de Gateway Playground.

Als de gebruiker niet geautoriseerd is, gebruiken we de OAuth2-clientinformatie in de integratie en loodsen we de gebruiker door de OAuth2 Authorisation code flow. Aan het einde van het proces slaat TrueFoundry de Access en Refresh Tokens (indien ondersteund en ingeschakeld) veilig op.

We kunnen onze inloggegevens verwijderen uit TrueFoundry of ze zelfs rechtstreeks intrekken bij de provider.

Aan de slag!

Zodra u geautoriseerd bent, kunt u de context van de MCP-servers rechtstreeks in onze Playground gebruiken.

Let op: we geven geen OAuth2-inloggegevens door aan de frontend. De frontend roept een API aan:

‍

LLM Gateway implementeert de "agentic" loop, waarbij de initiële berichten en de tool-beschrijvingen van de MCP Server naar de LLM worden gestuurd. De gebruiker kan ook de tools filteren die aan de LLM worden getoond. Op basis van de reactie van de LLM kan de LLM Gateway communiceren met de MCP Servers en de inloggegevens van de aanroeper doorgeven. We vernieuwen automatisch kortstondige inloggegevens. De updates worden via SSE naar de frontend gestuurd.

Conclusie

Deze combinatie van MCP + OAuth2 stelt onze collega's in staat om data van providers zoals Slack, GitHub, Sentry, enz. veilig te integreren in hun op LLM gerichte workflow.

Enkele toepassingen:

• LLM's kunnen via MCP toegang krijgen tot Sentry om foutdetails op te halen en deze te correleren met gerelateerde codewijzigingen uit GitHub voor snellere debugging.
• LLM's maken, updaten en raadplegen Jira-tickets via MCP, wat de workflows van ontwikkelaars stroomlijnt.
• LLM's kunnen via MCP toegang krijgen tot Slack-gesprekken om lange discussies te analyseren en samen te vatten, waardoor teams snel inzicht krijgen in besluiten en actiepunten zonder volledige chatgeschiedenissen te hoeven lezen.