Anthropic brengt koppelplatform voor AI-diensten onder bij Linux Foundation-tak

Anthropic gaat het beheer van zijn Model Context Protocol, dat het zelf aanduidt als 'USB-C-poort voor AI', onderbrengen bij de Agentic AI Foundation, dat onder de Linux Foundation valt. Vergelijkbare initiatieven als Agents.md en goose vallen onder diezelfde stichting.

Die Agentic AI Foundation is nieuw, zegt Anthropic. Het bedrijf is zelf een van de oprichters, samen met Agents.md-maker OpenAI en goose-maker Block. Google, Microsoft, Amazon, Cloudflare en Bloomberg zijn ook betrokken bij de stichting. De bedoeling daarvan is om AI-agents open en transparant te ontwikkelen met open standaarden.

Anthropic maakte MCP vorig jaar al opensource beschikbaar. Inmiddels zijn er al vier releases geweest van het protocol en zijn er bijna honderd miljoen maandelijkse downloads van de sdk van de standaard. Met MCP kunnen gebruikers AI-diensten koppelen aan bestandssystemen of andere webdiensten. Het is onder meer in gebruik om AI-chatbots te verbinden met databases. Ook kunnen AI‑diensten daardoor gebruikmaken van andere diensten en daardoor meer functies uitvoeren.

Door Arnoud Wokke

Redacteur Tweakers

10-12-2025 • 11:10

49

Reacties (49)

Sorteer op:

Weergave:

Dit is een goede stap. Laten we hopen dat die standaarden snel door alle partijen bredere ondersteuning krijgen, vooral de AGENTS.md, ik zie geen .aiignore, maar dat is ook echt een drama met al die verschillende varianten (.aiderignore, etc.).

Over MCP, ik gebruik het soms, maar het is een context vreter als je lokale modellen gebruikt. Dus wellicht is dat nog iets dat beter kan, tweaker djwise, gebruikt hiervoor skills en heeft gedeeld in een andere discussie hoe hij dat inzet, hopelijk gaan skills ook bredere ondersteuning krijgen, dat lijkt meer op een soort slimme lookup voor relevante context en die aanpak werkte lokaal een klein beetje beter (voor mij althans, maar heb er slechts een uur of drie meer getest).
Ik kwam er ook achter dat daar nogal verschil in is. Zelf gebruik ik copilot-instructions.md maar als entrypoint nu..
Wat doet deze "Usb-C poort voor AI" precies?
Simpel gezegd zorgt het ervoor dat externe diensten gekoppeld kunnen worden aan de AI agent. Dus stel dat jij een MCP hebt voor een CMS (content-management systeem), dan kan je AI vragen om post the maken op je website. Met een MCP kan die dan de API aanroepen van het CMS om een nieuw artikel aan te maken en de tekst te posten. Zonder MCP moet de AI agent eerst weten hoe die posts kan aanmaken op een website via de web-interface (en daar heeft die wellicht niet de rechten toe).

Daarom wordt het ook wel de USB voor AI genoemd. Het is een manier om allerlei dingen op een universele manier aan te koppelen.
Heeft dan niet iedere CMS een API nodig waarmee je content kan posten ? En zijn er dan connectors/interfaces tussen de MCP en de specifieke CMS API's en hun versies ?
Vim -> Agent(Model) -> MCP -> CMS-Connector -> CMS API Call ?
Ik zie het eerder evolueren naar een AI API (MCP) en een menselijke API. De MCP gaat anders voor het grootste deel van API calls zorgen op de publieke CMS endpoints, elke request onderhevig aan authenticatie en throttling logica.

MCP commando's kunnen (hoeven niet) serverside gebrokered worden bij het verwerken van je AI chat, waardoor je kan snijden in securitylagen, sneller kan antwoorden enz. wanneer het die API call stap kan overslaan.

Dat draagt deels bij aan een groot voordeel van AI in de cloud: het erft jouw authenticatie over waardoor het serverside je complexe antwoord verder kan uitrekenen m.b.v. database queries, netwerk searches enzovoort, terwijl jij ff je verbinding op de trein kwijt was. Gezien deze niet-zo-lichte processing in de cloud gebeurt en extra RAM nodig heeft, zie ik in de toekomst zo goed als alle diensten die AI implementeren naar een subscription based model evolueren.

Het is maar deels een antwoord op je vraag, maar ik ben te hyped over deze evolutie. 8)7 We verliezen als consument wel een pak controle de volgende jaren, waardoor de machtsmisbruik zoals in de VS veel makkelijker enabled wordt, dus m'n hype is enkel vanwege het technologische aspect..
Zit in jouw hoek qua hype. Ik zie zelfs een usecase voor blockchain |:(
Elk product met zijn eigen API zal zijn eigen MCP server nodig hebben. Zo zijn er dus ook MCP servers voor Docker, Kubernetes, Go language server, ... Een CMS was hier slechts een voorbeeld.
Kort gezegd niet heel veel anders dan de Common Gateway Interface (CGI) van 1993.

Functioneel maakt het je mogelijk bestaande of nieuw te schrijven services aan te spreken door een LLM tool op een standaard manier. Dit kan lokaal via de command line of via het web.

Eigenlijk is het een set van webservice afspraken geschikt voor LLM gebruik.

Het meest simpele voorbeeld is de huidige tijd laten invoegen in een antwoord.

MCP maakt onder water gebruik van JSON RPC. Door middel van SDKs voor Python, Java e.d. wordt het allemaal wat makkelijker gemaakt.

In geval van Spring-Boot (Java) kun je een bestaande webservice omkatten naar MCP door slechts webservice annotaties op de controller te vervangen door Spring AI MCPTool annotaties.

een voorbeeld service: https://github.com/nicenemo/mcp-example/blob/main/src/main/java/eu/hanskruse/mcpexample/ExampleTools.java

Voor een demo heb ik eerder dit jaar security tools van Kali Linux zo ontsloten. Inmiddels heeft de meeste recente release van Kali Linux MCP ondersteuning..

Grote nadeel van MCP is dat het context vreet, zoals ook door Anthropic in een paper is beschreven.
De artikelschrijvers proberen mensen aan te spreken met 0 technische kennis. Wat het ècht betekend is simpelweg dat Anthropic een paar protocollen gratis/opensource heeft gemaakt. En alle problemen mogen door de Linux Foundation opgelost worden :)
Ze waren al gratis en open source. Wat ze gedaan hebben is een open organisatie waar meerdere bedrijven en personen zich bij kunnen aansluiten eigenaar gemaakt. Dat betekend eigenaar van eventuele issues (wat die ook mogen zijn) en dat de doorontwikkeling en fixes in onderling overleg gebeuren en niet alleen bepaald worden door anthropic.

Al met al dus een positieve stap.
Waarom is dit een positieve stap en waarom moet dit onder de Linux Foundation terecht komen ?
Heeft dat werkelijk uitleg nodig of ben je aan het trollen?

sinds wanneer is een specificatie onder open beheer brengen een slecht ding? Zodat iedereen kan bijdragen en er van gebruik maken? En waarom niet die foundation. Ze hebben een hoop ervaring.
Ik zie niet in waarom dit per se bij de Linux Foundation moet ik dacht dat die enkel of toch voornamelijk Linux deden of toch dat dat het doel was toen het werd opgericht. Ik heb er ook ooit (wel al 15 jaar geleden) een paar sheckles naar gestuurd.
edit:
En hoe meer partijen kunnen beslissen hoe trager beslissingen worden gemaakt. is de Foundation zich niet te breed aan het inzetten ipv zich serieus bezig te houden met hun core business ?

[Reactie gewijzigd door goarilla op 10 december 2025 14:21]

Zoals het artikel stelt het komt bij een dochter van de foundation die met AI bezig is. Linux is in de naam, daar is het begonnen, maar ze doen meer.
CNCF (Cloud Native Computing Foundation)

OpenSSF (Open Source Security Foundation)

OpenJS Foundation

Vallen ook allemaal onder de Linux Foundation.
En het geeft andere partijen de mogelijkheid om iets aan het protocol bij te dragen/aan te passen.
wow wat een verhelderend en totaal niet cynische blik

Een beetje als


Ja god geeft dan wel de wereld en het universum geschapen maar nu zitten wij mooi met: huizen tekort, 3 potentiële wereldoorlogen, een paar potentiële Kernrampen etc
Je kan een hoop informatie vinden hierover op de website voor het Model Context Protocol (MCP) https://modelcontextprotocol.io/docs/getting-started/intro

In het heel erg kort bied het een standaaard manier aan om AI te laten koppelen met externe systemen. Zo kan je het bijvoorbeeld laten connecten met Figma zodat het bij het generen van websites houdt aan de design die je in Figma gedefinieerd hebt.
Wat ze hopen dat 1 standaard / in en outgangsport word voor AI toepassingen
Het is een standaard waarmee je, als het ware, add-ons kunt schrijven voor je LLM (Large Language Model). Een MCP server kan context en skills bieden, bijvoorbeeld een lijst met producten geven, waardoor de LLM weet welke producten beschikbaar zijn, of door de huidige datum en tijd te geven, of een rekenmachine zodat hij echt kan rekenen, etc. De mogelijkheden zijn eindeloos.

Maar MCP is dus vooral de standaard waar je deze externe contextproviders op in kunt pluggen.
De laatste keer dat ik er naar keek viel het mij op dat een groot deel van de standaard kan worden omschreven als "developers documenteer je API's eens fatsoenlijk" Een aantal functies met een omschrijving ala openAPI met duidelijke textuele omschrijvingen van in en output. De AI interpreteert op basis van de documentatie wat hij met een MCP server kan.
Ja dat is correct.

Om heel eerlijk te zijn heb ik sterk het idee dat het ook niks meer is dan OAS, maar dan "humab readable" in zijn geheel. OAS is als tool ondertussen veel verder gegroeid, met standaard responses en volledige JSON schema support.

MCP lijkt in dat opzicht meer op een "schrijf het maar gewoon op"
Niet zo heel lang geleden had iedere LLM 'maker' een eigen 'variant' van function calling. Bij de claude modellen hebben ze dat iets opgerekt met hun eigen MCP-standaard, waar ze meteen ook beschreven hoe je client en server kon implementeren om met hun modellen samen te werken naar een totaal oplossing. Daarbij hebben ze direct open source libraries gepubliseerd zodat mensen direct aan de gang konden met het 'nieuwe' MCP. En dat is dus nu een open standaard geworden.

En recent, hebben ze een andere aanpak gekozen met skills. Die m.i. beter omgaan met context in de modellen, want context is hetgeen dat moeizaam schaalt in de modellen. Of het werkt niet lekker met recall (dat zijn die mooie 'ballenbakken' met kleurtjes die je vorig jaar zag in de presentatie van google gemini en gemma), of het gebruikt veel geheugen (en is daardoor duur). Sowieso is grotere context uberhaupt al lastiger want alle modellen werken nu eenmaal het beste met de meest recente tokens (even alle modellen over een kam die text genereren met transformers en niet alternatieve designs zoals mamba).
Heeft niks met usb c te maken. Het is simpelweg een protocol voor AI om data op te halen uit een database. Het is daardoor eerder vergelijkbaar met http in mijn beleving
Het heeft ook niks inherent te maken met een database, het is gewoon een enigszins gestandaardiseerde aanpak aan het worden om een LLM met je applicatie te laten interfacen middels MCP, of die nou een database heeft of niet. Nog even en elke zichzelf respecterende applicatie heeft wel een MCP-ingang.

[Reactie gewijzigd door MsG op 10 december 2025 12:03]

Heeft niks met usb c te maken.
Ik denk dat @Lnaisd de beeldspraak wel begrijpt want hij gebruikt de quotes correct. Hij vraagt naar de inhoud.

Het is ook niet vergelijkbaar met http anders dan dat beiden standaarden zijn. MCP kan lokaal via Pipes, of via HTTP of via eigenlijk elk ander transport. De standaard specificeert dit niet. Alleen wat er gecommuniceerd word staat er in en hoe.
Goed dat grote spelers als Google en Microsoft meedoen. Hopelijk blijft het niet bij mooie woorden maar wordt het ook echt open en transparant.
Goed dat grote spelers als Google en Microsoft meedoen
dat maakt het wat mij betreft een standaard die direct veel te traag gaat.

Microsoft is echt niet snel als het gaat om standaarden en legacy drops.
Je roept iets generieks, maar de integratie van MCP gaat juist veel te snel bij MS. Nu al in Windows gooien terwijl het vol veiligheidsrisico's zit. Geldt eigenlijk voor bijna overal waar MCP ingezet wordt. Het heeft veel potentie en toegevoegde waarde, maar de integratie gaat te haastig.
maar de integratie van MCP gaat juist veel te snel bij MS
ja dat is juist wat ik zeg. Legacy drops zijn ze heel traag in dus waar ze nu overal integreren, moeten ze straks heel veel blijven onderhouden als legacy, en dat is niet goed voor de standaard want die zal dan langer backwards compatible moeten zijn "omdat Microsoft en enterprise".

Ik weet niet of je die MCP registry voor windows 11 al gezien had, maar MS is echt veel te hoog van de toren aan het blazen met AI terwijl het de basis nog niet op orde heeft.

https://www.reddit.com/r/LocalLLaMA/comments/1kqluy9/microsoft_just_created_an_mcp_registry_for_windows/
MCP on Windows provides the Windows On-device Agent Registry (ODR), a secure, manageable interface to discover and use agent connectors from local apps and remote servers using Model Context Protocol (MCP). MCP is an open protocol designed to standardize integrations between AI apps and external tools and data sources. By using MCP on Windows to discover and interact with MCP servers, app developers can enhance the capabilities of AI models, enabling them to produce more accurate, relevant, context-aware responses, and to expand the tasks they can complete for users.
Dit wordt echt nog wel een ding hoor. Opzich wel handig, maar ik ben er erg huiverig voor dat MS dit goed kan.
Het is al open en transparant
MCP is een rommelig in elkaar gehackt protocol dat een hoop vooruitgang de komende jaren gaat tegenhouden.

Een van de problemen is dat het voortborduurt op de limitaties van JS / JSON omdat de lowest common denominator is geworden.

Nu is het allemaal prachtig, maar over een paar jaar is het “hadden we maar”.
In welk opzicht denk je dat het limiterend gaat zijn, het is letterlijk "any JSON" volgens een opgegeven specificatie. Aangezien de "generator" (LLM) enkel tekst uitvoer heeft. Het is eigenlijk uiterst flexibel voor het geven van opdrachten aan andere diensten.
  • Iedere MCP connectie vreet van je context window, behalve Claude Code waarschijnlijk, want die heeft zijn eigen tools naar ik verwacht al in zijn model zitten
  • Niet iedere tool die via MCP gekoppeld wordt, wordt ook echt begrepen door de MCP LLM client. En dat wordt erger naar mate je meer tools hebt die ongeveer het zelfde claimen te doen
  • Onduidelijk hoe veel tools daadwerkelijk gebruiken aan tokens / context, bijvoorbeeld een search door een tool grep te doen of door alle documenten in te laden: dat laatste is duur en inefficient
  • Security is achteraf, half, toegevoegd
  • MCP vraagt toestemming voor iedere actie, of het nou het zoeken in een directory is of "rm -rf in root" is. Ik ram ze bijna blind door altijd, als ik moe begin te worden
  • Het is allemaal question / answer als in HTTP, maar er moet ook een dialoog mogelijk zijn waarbij de tool vragen terug kan stellen, oftewel "state management"
Ik ben een zware gebruiker van Claude Code, en had ook de gewone Claude via een MCP server gebruikt toen met de base Pro Claude Code nog niet mogelijk was. Het is echt fantastisch wat er mee kan, bijna magisch en daarom is het ook zo snel populair geworden. Maar met name het laatste punt is heel, heel ingewikkeld om nog binnen de MCP standaard netjes op te leveren, zonder een compleet nieuw protocol te beginnen.

Audio, afbeeldingen en video worden ook ondersteund volgens mij

[Reactie gewijzigd door BikkelZ op 10 december 2025 14:39]

De tools beschrijven kosten inderdaad context window, maar hoe zou je dat anders willen zien, de LLM moet immers weten waar het over gaat. Hier zijn wel (oplossingen) voor als dynamic tool discovery (basically, een tool welke je kan vragen welke andere tools er zijn zodat hij alleen die tools in de context window laad.

En ja, ik kan me voorstellen dat vergelijkbare tools niet altijd even lekker samenwerken, misschien dat het beter gaat met dynamic tool discovery.

En ja, je moet je tool wel zo opzetten dat als je iets vraagt over een website met CMS dat hij niet het hele CMS ineens "leest" maar enkel de relevante delen. Toestemming vragen is per tool is een client side iets, bij bijvoorbeeld Claude Code kan je in een configuratie bestand aangeven van: "dit is allemaal toegestaan". De LLM roept immers niets aan, hij stuurt enkel maar een json terug met "roep deze functie zelf aan met deze argumenten".

Terugvragen is er toch wel, ook in Claude Code, tool wordt uitgevoerd, antwoord terug met inhoud, LLM kijkt er na en kan een opvolgende tool aanroepen.

Als je zelf tools maakt zijn simpele dingen op zich prima te doen, maar als je echt specifiek gedrag wat verder gaat dan "maak pagina x in cms y" wilt doen heb je wel ook nog veel context nodig voor prompts, maar dat verschilt erg per model wat je gebruikt.
CC gebruikt veel simpele tools die het dan coördineert, maar kan geen complexe “gesprekken” aan gaan met een “evenknie”
A2A en MCP zijn beide gewoon een protocol met een berg JSON docs en wat API's bij elkaar.

Is het hele "AI" niet over een paar jaar: "Hadden we maar...."
Ik heb een MCP nog nooit netjes zien werken, je moet altijd superduidelijk aangeven "GEBRUIK DE MCP" en dan nog steeds kan het fouten ermee maken en de MCP negeren omdat er geen goede info uitkomt. En dit is niet met oude modellen, zelfs de SOTA heeft er best wat moeite mee. In mijn opinie is dit toch nog verre van wat we willen qua 'usb-c voor AI'.
das toch niet zo gek? Je moet in iedere prompt ook de tool omschrijving leveren zodat het model ook kan weten wat het kan doen en hoe het dat in moet zetten.
ik gebruik copilot in mijn IDE met agentic mode, daar kan hij zelf vanalles uitvogelen en krijgt ook automatisch alle defenities mee. Jammergenoeg werken de MCPs niet echt intuitief dus worden die nogal snel uit het raam gegooid in favor of command line alternatieven etc.
en krijgt ook automatisch alle defenities mee
keyword being automatisch.

Met N8N moet je dat bijvoorbeeld wel nog zelf doen.
Misschien is het wel USB 1.1 voor AI?
Statistieken als 'honderd miljoen maandelijkse downloads' vind ik een lastige indicatie van het bereik of relevantie. Hoeveel hiervan zal onderdeel zijn van een build pipeline met beperkte impact?
Die stelling telt voor elke download. Dus je kan de relatieve waarden nog steeds tegenover elkaar vergelijken. Het duid in ieder geval aan dat het gebruikt word. Het komt niet in een build pipeline omdat developers het niet inzetten.
@arnoudwokke ik vind deze titel nogal onduidelijk, maar snap de metafoor. Misschien kun je de volgende keer een iets duidelijkere titel kiezen.
Mja hij heeft dat ook denk ik gewoon gecopy-paste van Anthropic. En hier staat het ook: https://modelcontextprotocol.io/docs/getting-started/intro.
edit:
Jij doelt wellicht op "koppelplatform" in de titel en niet USB-C er juist onder
Sorry, foutje ?

[Reactie gewijzigd door goarilla op 10 december 2025 19:18]

De USB-C van AI stond ook in de titel, het was een A/B test. Ik bedoelde die van USB-C

Op dit item kan niet meer gereageerd worden.